Слой службы и структура проекта в ASP.NET MVC 5 без репозитория и шаблонов UoW

Нет причин использовать шаблон единицы работы с Entity Framework, если вам не нужно создавать общий механизм доступа к данным. Вы бы сделали это, только если бы вы были:

1. с использованием технологии доступа к данным, которая изначально не поддерживает шаблон единицы работы (EF поддерживает)
2. Хотел иметь возможность поменять местами поставщиков данных когда-нибудь в будущем.. однако это не так просто, как может показаться, поскольку очень сложно НЕ вводить зависимости от конкретных технологий данных даже при использовании единицы работы (возможно, даже ПОТОМУ ЧТО вы есть)... или
3. Вам нужен способ объединения разрозненных источников данных в атомарную транзакцию.

Если ни один из них не имеет места, вам, скорее всего, не нужна пользовательская единица работы. С другой стороны, репозиторий может быть полезен... но с EF6 также доступны многие преимущества репозитория, поскольку EF6 предоставляет фиктивные интерфейсы для тестирования. Тем не менее, держитесь подальше от универсального репозитория, если это не просто деталь реализации ваших конкретных репозиториев. Предоставление общих репозиториев другим слоям — это огромная утечка абстракции...

Я всегда использую шаблон Repository/Service/Façade, чтобы создать разделение между моими данными и бизнес-слоями (и пользовательским интерфейсом и бизнесом, если уж на то пошло). Он предоставляет удобный способ имитации без необходимости имитировать сам доступ к данным и отделяет вашу логику от специфики, представленной уровнем Linq, используемым EF (Linq является относительно универсальным, но есть вещи, специфичные для EF). интерфейс фасад/репозиторий/сервер разделяет это).

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

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

Например, вы можете реализовать создание новой учетной записи в качестве многоэтапного мастера в своем пользовательском интерфейсе, для этого потребуется другая проверка, чем на вашем бизнес-уровне, поскольку каждый шаг имеет только подмножество проверки всего объекта. Или вам может потребоваться, чтобы ваш мобильный интерфейс имел другие требования к проверке от вашего веб-сайта (например, один может использовать капчу, а другой может использовать человеческую проверку на основе касания).

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

Хорошо, давайте проясним некоторые вещи...

Понятие ViewModel (или фактическая формулировка ViewModel) введено Microsoft Мартин Фаулер. На самом деле, ViewModel — это не что иное, как простое class.

На самом деле ваши Views строго типизированы до classes. Период. Чтобы избежать путаницы, была предложена формулировка ViewModel, чтобы помочь людям понять, что

«этот класс будет использоваться вашим представлением»

поэтому мы называем их ViewModel.

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

На самом деле, вы когда-нибудь замечали, почему внутри приложения MVC есть папка Models, а не папка ViewModels?

Кроме того, вы когда-нибудь замечали, что в верхней части представления у вас есть директива @model, а не директива @ viewmodel?

Это потому, что все может быть моделью.

Кстати, для ясности, вы можете удалить (или переименовать) папку Models и создать новую с именем ViewModels, если это поможет.

Независимо от того, что вы делаете, в конечном итоге вы будете называть @model, а не @viewmodel вверху страницы.

Другим подобным примером может быть DTO classes. Классы DTO — это не что иное, как обычные классы, но они имеют суффикс DTO, чтобы помочь людям (программистам) различать все остальные классы (включая модели представления).

В недавнем проекте, над которым я работал, это понятие не было полностью понято командой, поэтому вместо того, чтобы их Views строго типизировали до Models, их Views строго типизировали до DTO classes. В теории и на практике все работало, но вскоре они обнаружили, что у них есть такие свойства, как IsVisible внутри их DTO, когда на самом деле; такие свойства должны принадлежать вашим ViewModel классам, поскольку они используются для логики пользовательского интерфейса.

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

Еще одна вещь, которую я хотел бы отметить, это то, что если и только если ваш Service Layer планирует обслуживать другие вещи, такие как приложение Winform, мобильный веб-сайт и т. д., то ваш Service Layer не должен получать ViewModels.

Ваш Service Layer не должен иметь представления о том, что такое ViewModel. Он должен только принимать, получать, отправлять и т. д. классы POCO.

Это означает, что из вашего Controller внутри вашего ActionResult, как только ModelState станет Valid, вам нужно преобразовать ваш ViewModel в POCO, который, в свою очередь, будет отправлен методу внутри вашего Service Layer.

Другими словами, я бы использовал/установил пакет Automapper nugget и создал несколько методов расширения, которые преобразовали бы ViewModel в POCO и наоборот (POCO в ViewModel).

Таким образом, ваш метод AddNewPerson() получит объект Person для своего параметра вместо получения параметра PersonViewModel.

Помните, это справедливо только для if and only if ваших Service Layer планов по обслуживанию других вещей...

Если это не так, то не стесняйтесь, чтобы ваши Service Layer получали, отправляли, добавляли и т. д... ViewModels вместо POCO. Это зависит от вас и вашей команды.

Помните, что есть много способов снять шкуру с кошки.

Надеюсь это поможет.