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

Няма причина да използвате модел на единица работа с Entity Framework, ако не е необходимо да създавате общ механизъм за достъп до данни. Бихте направили това само ако сте:

1. използване на технология за достъп до данни, която първоначално не поддържа модел на единица работа (EF го прави)
2. Исках да мога да сменям доставчиците на данни някога в бъдещето... това обаче не е толкова лесно, колкото може да изглежда, тъй като е много трудно да НЕ се въведат зависимости от конкретни технологии за данни, дори когато се използва единица работа (може би дори ЗАЩОТО вие са)... или
3. Трябва да имате начин да обединявате различни източници на данни в атомна транзакция.

Ако нито един от тези случаи не е такъв, най-вероятно нямате нужда от персонализирана единица работа. От друга страна, хранилището може да бъде полезно... но с EF6 много от предимствата на хранилището също са налични, тъй като EF6 предоставя подигравателни интерфейси за тестване. Независимо от това, стойте далеч от генерично хранилище, освен ако не е просто детайл от изпълнението на вашите конкретни хранилища. Излагането на генерични хранилища на другите ви слоеве е огромно изтичане на абстракция...

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

Като цяло сте на прав път... Позволете ми обаче да отбележа, че използването на атрибути на данни във вашите модели на изглед е нещо добро. Това централизира вашето валидиране на вашия модел, вместо да ви накара да поставите логика за валидиране навсякъде.

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

Например, можете да внедрите създаването на нов акаунт като многоетапен съветник във вашия потребителски интерфейс, това ще изисква валидиране, различно от вашето бизнес ниво, тъй като всяка стъпка има само подмножество от валидирането на целия обект. Или може да изисквате вашият мобилен интерфейс да има различни изисквания за валидиране от вашия уеб сайт (единият може да използва captcha, докато другият може да използва базирано на докосване човешко валидиране например).

Така или иначе, важно е да имате предвид, че валидирането е важно както на клиента, сървъра, така и на различни слоеве...

Добре, нека изясним някои неща...

Понятието ViewModel (или действителната формулировка на ViewModel) е нещо, въведено от Microsoft Мартин Фаулър. Всъщност ViewModel не е нищо повече от обикновено class.

В действителност вашите Views са строго въведени до classes. Месечен цикъл. За да се избегне объркване, формулировката ViewModel се появи, за да помогне на хората да разберат това

„този клас ще се използва от вашия изглед“

затова ги наричаме ViewModel.

Освен това, въпреки че много книги, статии и примери използват думата ViewModel, нека не забравяме, че това не е нищо повече от просто Model.

Всъщност, забелязали ли сте някога защо има папка Models вътре в MVC приложение, а не папка ViewModels?

Също така, забелязали ли сте някога как в горната част на View имате директива @model, а не директива @ viewmodel?

Това е така, защото всичко може да бъде модел.

Между другото, за по-голяма яснота, можете да изтриете (или преименувате) папката Models и да създадете нова, наречена ViewModels, ако това помага.

Независимо какво правите, в крайна сметка ще извикате @model, а не @viewmodel в горната част на страниците си.

Друг подобен пример би бил DTO classes. DTO класовете не са нищо повече от обикновени класове, но те имат суфикс с DTO, за да помогнат на хората (програмистите) да правят разлика между всички останали класове (включително View Models).

В скорошен проект, върху който работих, това понятие не беше напълно разбрано от екипа, така че вместо техните Views строго въведени на Models, те щяха да имат своите изгледи строго въведени на 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. Това зависи от вас и вашия екип.

Не забравяйте, че има много начини да одерете котка.

Надявам се това да помогне.