EF-сущности как доменные модели, когда они отделены от представлений моделями представлений? - PullRequest
Новая
       24

EF-сущности как доменные модели, когда они отделены от представлений моделями представлений?

3 голосов
/ 15 апреля 2011

Я пытаюсь понять лучшую архитектуру для моего сайта MVC2.

Поскольку я экспериментировал с получением данных в базу данных и из нее с помощью Entity Framework, я начинаю понимать простую область-модели, которые я до сих пор построил, не соответствуют всем потребностям моих плановых представлений.Итак, я рассматриваю следующий ответ на этот вопрос: Почему два класса, модель представления и модель предметной области? .

Но, похоже, существует избыточность с небольшой отдачей, которую я могу ощутить междудоменные модели и модели EF, и я даже не могу понять концептуальную разницу.У меня нет требования переключать источники данных в будущем, и я также не вижу необходимости менять свое решение ORM.

ВОПРОС:
Если я следую этому шаблону, то, поскольку я использую Entity Framework, не должен ли я просто использовать свои EF-сущности для непосредственного использования в качестве моделей предметной области?(примечание: я не продумал «как», но ответы там тоже приветствуются.) Или мне все-таки советуют управлять отдельным набором доменных моделей?

1 Ответ

6 голосов
/ 15 апреля 2011

Кажется, у вас есть некоторая избыточность здесь.Читая ваш абзац:

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

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

Однако классы моей модели домена не совпадают с моими моделями представления.Класс модели Домена может содержать данные, которые не интересны для Представления, или может быть представление нуждается в информации, которая рассчитывается / оценивается на основе информации в представлении.Простым примером может быть: 

public class Session // Domain model (and EF Model
{
    public int Id {get; set; }
    public DateTime Start {get; set; }
    public int DurationInMinutes {get; set; }

}

public class SessionViewModel // The viewmodel :p
{
   public DateTime Start {get; set; }
   public int DurationInMinutes {get; set;}
   public DateTime End 
   {
       get
       {
            return Start.Add(TimeSpan.FromMinutes(DurationInMinutes));
       }
   }
}

В этом примере меня интересует отображение фактического времени окончания в моем представлении, но я не заинтересован в его сохранении в базе данных, поскольку это может привести кнесоответствия данных ( DurationInMinutes + Start может не совпадать с End, если данные повреждены при сохранении )

Когда я впервые начал кодировать таким образом, я закончил тем, что выполнял много ручной работы, отображая модели моего доменав ViewModels и обратно.AutoMapper изменил все это :) Google или NuGet, и это сделает вашу жизнь намного проще:)

Надеюсь, это немного поможет.Пожалуйста, прокомментируйте, если я полностью упускаю из виду:)

Обновление для адресации комментария

Затем DataAnnotations будут применяться к ViewModel, потому что обычно DataAnnotations обозначают, какданные должны отображаться и проверяться в представлении.

Например, вы бы поставили атрибут [Required] на public DateTime Start {get; set;}, чтобы расширения Html.DisplayFor автоматически проверяли ваш HTML в соответствии с вашими аннотациями данных.

По определению (по крайней мере, некоторыми)Модель предметной области не должна содержать никакого кода или логики, связанной с вашей бизнес-логикой.Модель предметной области просто отвечает за то, что содержит довольно сырые данные в соответствии с вашим хранилищем данных.Лично мне нравится помещать какой-то слой Service между ними, который отвечает за выборку данных и возврат ViewModels, а также делает обратное.

Конечная цель состоит в том, чтобы не ссылаться на вашу доменную модель напрямую с ваших контроллеров.

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

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

...