Entity vs Model vs View Model

Я просто потратил некоторое время на чтение этих терминов (я их не так много использую, так как у нас нет каких-либо приложений MVC, и я обычно говорю "модель" ), но у меня такое ощущение, что это означает разные вещи в зависимости в контексте:

Entity

Это довольно просто, это одна строка в базе данных:

2) В отношении базы данных объект - это одно лицо, место или о том, какие данные можно сохранить.

Model

Я часто читаю, это в основном комбинация сущностей для представления полного набора данных, пусть, например, модель списка адресов клиента объединяет клиентов, адреса и, возможно, отдельных лиц.

ViewModel

Термин в шаблонах MVVM или MVC, который является моделью, которая представляет собой точно данные, которые вы можете видеть в представлении. Модель просмотра находится на уровне приложения и имеет атрибуты для проверки, т.е. ASP.NET MVC Model vs ViewModel

С моей точки зрения, эти термины кажутся немного избыточными: Viewmodel, очевидно, использует его, в противном случае вид должен был бы сделать всю тяжелую работу, чтобы показать правильные вещи. Сущность - это просто представление, как мы знаем из EF, но если вы объедините эти два, где модель использует его?

Вещи, такие как проверка, безопасность и т.д., должны выполняться в ViewModel. Используете ли вы модель, когда у вас есть сотни небольших таблиц, чтобы добавить другую абстракцию между объектами и моделью просмотра? Или в терминах MVC и MVVM-объектов и моделей обычно одинаковы?

Как обычно спасибо и приятные выходные

Маттиас

ОТВЕТЫ

Ответ 1

Различные люди понимают эти термины несколько иначе, но я так понимаю:

Объект - объект, имеющий идентификатор (ID), обычно поступает из базы данных. Довольно простой класс.

Модель - любой бизнес-объект, это своего рода широкий термин. Это может быть сущность, какой-то пользовательский класс, который вы создали в своем проекте и т.д. Это почти все, что не является видом или контроллером/моделью просмотра.

ViewModel - какой-то посредник между моделью и представлением. Он модулирует связь между моделью и представлением, например, применяет проверку, объединяет больше моделей в один более крупный объект и т.д. Для целей взаимодействия с конкретным видом. ViewModel также отвечает за обработку событий (например, нажатия кнопок мыши), поэтому он предоставляет команды для представления, которое вы связываете с (WPF).

Ответ 2

Термин "Модель" неоднозначен. Все они модели.

Модель сущности

Класс, который очень похож на структуру в постоянстве. MemberEntity - это модель, представляющая одну строку элемента в таблице Members в базе данных. Не строго привязан к базе данных, но какой-то сущности какой-то персистентности. Обычно имеет свойство "ID", например, int MemberID.

ViewModel

Класс, который очень похож на структуру в View/UI. MemberViewModel - это модель, представляющая одного члена, который будет отображаться в представлении/пользовательском интерфейсе пользователя на внешнем интерфейсе приложения. Не строго привязан к шаблону MV *.

Обратите внимание

... что две вышеупомянутые модели представляют связь на границах приложения. То есть передняя граница (точка входа), которая принимает связь (пользовательские события и связь по протоколу) для инициирования бизнес-правил; И задняя граница, которая принимает команды из бизнес-правил для открытия связи с другими системами (такими как базы данных или другие конечные точки).

Модель предметной области

Класс, который представляет часть проблемной области. MemberModel отвечает за его создание и проверку. Поскольку сервисы принимают и возвращают модели, модели отвечают за свою собственную бизнес-логику, которая подтверждает правильность их построения и использования. Е.Г.: MemberModel должен сломаться, если вы попытаетесь использовать его без имени пользователя.

Доменные службы

Доменные службы берут Entity Models и преобразуют их в Domain Models, чтобы указанные службы могли работать с этими моделями. Если сущность входит с задней границы и не может сериализоваться или отобразиться в Domain-Model, появляется красный флаг, что данные неверны.

Доменные службы берут доменные модели и сопоставляют их с объектами, чтобы отправить их за черту. Если задняя граница (DB/SDK?) Не может принять модель, DB/SDK необходимо исправить.

  • Примечание. Объекты соответствуют моделям, поскольку постоянство - это деталь. Домен - это король системы, а не аппаратная или табличная структура постоянства. Домен никогда не ошибается.

Передние границы берут ViewModels и преобразуют их в доменные модели, чтобы их можно было передавать в домен. Если ViewModel не удается сериализовать или отобразить в Domain-Model, появляется красный флаг, что представление /json/xml плохое.

Доменные службы возвращают доменные модели на переднюю границу, которые затем сопоставляются с ViewModels для связи с передней частью. Если View/UI не может принять модель, View необходимо исправить.

  • Примечание. ViewModels соответствуют моделям, потому что потребители - это деталь. Домен - это король системы, а не пользовательский интерфейс или суб-приложения, которые их используют. Домен никогда не ошибается.

ViewModel НИКОГДА не знает о сущности, потому что пользовательский интерфейс/потребитель никогда не знает, что постоянство даже существует.

Основная бизнес-логика не должна знать о ViewModels или сущностях. Базовая бизнес-логика работает только с моделями доменов. Вот почему существуют контроллеры и ближайшие сервисы Frontend; Чтобы сопоставить доменные модели & lt; => ViewModels. Именно поэтому существуют SDK и расположенные рядом с ними Backend-сервисы; Чтобы сопоставить DomainModels & lt; => Сущности.

Когда система построена, сначала строятся домен и бизнес-логика (надеюсь, TDD). Затем адаптеры помещаются на лицевую и обратную сторону бизнес-логики, определяющей механизм доставки (внешний интерфейс) и зависимости (сервис/постоянство) (внутренний интерфейс). Но эти интерфейсы и бэкэнды могут быть разорваны, и основная бизнес-логика все еще существует.

Укороченная версия (TLDR;):

Сущность: запись базы данных.

Модель предметной области: специфичная для модели бизнес-логика (Google "Объект-значение") для представления объекта в проблеме предметной области.

ViewModel: страница (или раздел) представления.

Ответ 3

Я понимаю, что Модель является центральным понятием здесь, она отражает понимание решаемой проблемы. Объекты определяют, как объекты модели будут храниться в базе данных. Модели Viewmodels определяют, какая часть модели будет показана конечному пользователю.

Ответ 4

Определение этих терминов довольно неоднозначно. Вы найдете разные определения в разных местах.

Сущность: Сущность представляет отдельный экземпляр объекта вашего домена, сохраненный в базе данных в виде записи. У него есть некоторые атрибуты, которые мы представляем в виде столбцов в наших таблицах.

Модель. Модель обычно представляет собой объект реального мира, связанный с проблемой или доменным пространством. В программировании мы создаем классы для представления объектов. Эти классы, известные как модели, имеют некоторые свойства и методы (определяющие поведение объектов).

ViewModel. Термин ViewModel происходит от шаблона проектирования MVVM (модель View ViewModel). Есть случаи, когда данные, которые будут отображаться представлением, поступают из двух разных объектов. В таких сценариях мы создаем класс модели, который состоит из всех свойств, требуемых представлением. Это не модель домена, а ViewModel, потому что конкретное представление использует его. Кроме того, он не представляет объект реального мира.

Для получения более подробной информации посетите мой пост в блоге: Entity vs Model vs ViewModel vs DataModel

Ответ 5

Различные люди определяют Entity, Model и ViewModel разными способами. Однако эти термины иногда могут отличаться от их фактического значения, основанного на контексте.

Объект

Сущность - это табличное представление вашего класса/объекта домена в базе данных и имеет идентификатор. Фактически, объект представляет собой один экземпляр вашего объекта домена, сохраненного в базе данных, в качестве записи. Он имеет некоторые атрибуты, которые мы представляем в виде столбцов в наших таблицах.

Например, чтобы представлять Заказчика как сущность, он должен иметь некоторые атрибуты, такие как CustomerId, CustomerName, Address и многое другое в зависимости от контекста. Следовательно, эти атрибуты формируют столбцы таблицы Customer. И поэтому данные каждого клиента, которые вы сохраняете в таблице, представляют собой объект клиента.

Model

Люди часто путают сущность с моделью. Однако эти два совершенно разные. Модель обычно представляет объект реального мира, который связан с проблемой или доменным пространством. Во время программирования мы создаем классы для их представления. Эти классы, известные как модели, имеют некоторые свойства и методы (определяющие их поведение) в определенном доменном пространстве. Например, в любой проблеме, ориентированной на клиента, у нас может быть класс клиентов, который имеет некоторые свойства и методы.

В некоторых структурах ORM (Object Relational Mapper) модель тесно связана с сущностью. Это означает, что каждое скалярное свойство отображает атрибут сущности. Однако, если вы знакомы с Entity Framework, вы должны знать, что не все свойства в карте класса домена соответствуют столбцу объекта. И это один из способов, в котором сущность отличается от модели.

ViewModel

Термин ViewModel исходит из шаблона проектирования MVVM. В шаблоне проектирования MVVM это viewmodel, который содержит всю логику для обработки запроса/событий, генерируемых представлением. Можно сказать, что модель просмотра в шаблоне MVVM похожа на контроллер в шаблоне MVC.

Однако есть еще одна сторона. Представление несет ответственность за передачу данных, обычно поступающих от объекта. Однако есть примеры, когда данные поступают из двух разных объектов. В таких сценариях мы создаем класс модели, который состоит из всех свойств, необходимых для представления. Различные экземпляры модели домена затем инициализируют этот объект. Это не модель домена, а viewmodel, потому что конкретное представление использует ее. Кроме того, он не представляет собой объект реального мира.