Іменування конвенцій DAL, BAL та шару інтерфейсу користувача [закрито]

Я розробляю типовий веб-додаток із наступними шарами

1. Шар інтерфейсу (MVC)
2. Бізнес-логічний шар (BAL)
3. Шар доступу до даних (DAL)

У кожного шару є власний об'єкт DTO, включаючи BAL та DAL. Мої запитання щодо цього наступні

1. DTO, повернутий DAL, просто перетворюється на відповідний DTO у BAL та надсилається на шар інтерфейсу. І атрибути, і структура об'єктів DTO в одних випадках однакові. У таких сценаріях краще просто повернути DTO в DAL до рівня інтерфейсу користувача, не включаючи проміжний об'єкт.

2. Який найкращий спосіб називати ці об’єкти DTO та інші об'єкти в кожному шарі. Чи варто використовувати якийсь префікс, такий як DTOName, ServiceName? Причина, чому я прошу використовувати префікс, полягає в тому, що якщо не класи в моєму Solution зіштовхуються з іншими класами в Framework і з префіксом, мені легше зрозуміти, куди належить кожен клас?

Передмова

Сподіваюся , це очевидно, але ... в пропонованих просторів імен нижче, ви б замінити MyCompanyі MyProjectз реальними іменами вашої компанії і проекту.

DTO

Я рекомендую використовувати однакові класи DTO на всіх шарах. Так мало пунктів обслуговування. Я зазвичай розміщую їх під MyCompany.MyProject.Modelsпростором імен, у власному однойменному проекті VS. І зазвичай я називаю їх просто за реальною сутністю, яку вони представляють. (В ідеалі таблиці таблиць баз даних також використовують однакові імена, але іноді має сенс налаштувати схему дещо інакше.)

Приклади: Person, Address,Product

Залежності: Немає (крім стандартних .NET або бібліотек помічників)

DAL

Мої особисті переваги тут - використовувати набір класів DAL один за одним, що відповідає класам DTO, але у MyCompany.MyProject.DataAccessпросторі імен / проект. Імена класів тут закінчуються Engineсуфіксом, щоб уникнути конфліктів. (Якщо цей термін вам не подобається, то і DataAccessсуфікс також буде добре працювати. Просто будьте узгоджені з тим, що ви вибрали.) Кожен клас надає прості параметри CRUD, що впливають на базу даних, використовуючи класи DTO для більшості вхідних параметрів та типів повернення (всередині загальний, Listколи існує більше одного, наприклад, повернення від Find()методу).

Приклади: PersonEngine, AddressEngine,ProductEngine

Залежності: MyCompany.MyProject.Models

BAL / BLL

Також тут відображається індивідуальне відображення, але в MyCompany.MyProject.Logicпросторі імен / проекту та з класами, що отримують Logicсуфікс. Це повинен бути єдиний шар, який викликає DAL! Заняття тут часто є простим переходом до DAL, але якщо & коли потрібно застосовувати правила бізнесу, це місце для цього.

Приклади: PersonLogic, AddressLogic,ProductLogic

Залежності: MyCompany.MyProject.Models,MyCompany.MyProject.DataAccess

API

Якщо є рівень API веб-служб, я використовую той самий підхід «один за одним», але в MyCompany.MyProject.WebApiпросторі імен / проекту, з Servicesсуфіксом класу. (Якщо ви не використовуєте веб-API ASP.NET, в цьому випадку ви, звичайно, Controllerзамість цього використовуєте суфікс).

Приклади: PersonServices, AddressServices,ProductServices

Залежності: MyCompany.MyProject.Models, MyCompany.MyProject.Logic(ніколи не перепускний це, викликаючи DAL безпосередньо!)

Спостереження за бізнес-логікою

Здається, все частіше люди залишають BAL / BLL і замість цього застосовують бізнес-логіку в одному або декількох інших шарах, де це має найбільш сенс. Якщо ви це зробите, будьте абсолютно впевнені, що (1) весь код програми проходить через рівень (и) з діловою логікою, і (2) це очевидно і / або добре задокументовано, де було реалізовано кожне конкретне ділове правило. Якщо ви сумніваєтеся, не намагайтеся цього вдома.

Заключна примітка про архітектуру рівня підприємства

Якщо ви перебуваєте у великій компанії чи в іншій ситуації, коли одні й ті ж таблиці баз даних діляться у кількох програмах, я рекомендую не залишати MyProjectчастину вищевказаних просторів / проектів. Таким чином ці шари можуть бути спільними для декількох прикладних додатків (а також закулісних утиліт, таких як Windows Services). Але робіть це лише в тому випадку, якщо у вас є міцна взаємодія в команді та ретельне автоматизоване тестування регресу на місці !!! В іншому випадку зміна однією командою спільного основного компонента, ймовірно, порушить програму іншої команди.

Я зазвичай будую додаток як

ProjectName.Core            // "framework"/common stuff
|- Extenders
|- Gravatar.cs

ProjectName.DataProvider    // database provider layer
|- Migrations
|- ApplicationDbContext.cs  // entity framework

ProjectName.Domain          // database objects
|- Post.cs
|- Tag.cs

ProjectName.Services        // validations, database stuff
|- PostService.cs

Він дещо схожий на Sharp-Lite .

Про префікси я ненавиджу їх. Вказівки щодо внутрішнього кодування Microsoft також ненавидять їх. Також є інструмент під назвою StyleCop, який скаржиться і на префікси.