3-х слойная архитектура довольно популярна, но что она на самом деле означает?
- Презентационный слой
- Прикладной уровень
- Слой базы данных
Если вы спросите, что означает каждый слой, вы можете быть уверены, что получите несколько разных ответов. Вы можете далее разделить каждый слой на подслой и построить слоистый ад, как:
- Уровень представления на стороне клиента
- Слой вида со стороны сервера
- Контроллер слоя
- Служебный фасадный слой
- Сервисный слой
- Слой объектов домена
- Хранилище + Фабричный слой
- ORM слой
- Слой хранимой процедуры
- Слой вида базы данных
- Слой таблицы базы данных
WTF? Это всего лишь пример того, что приложение может быть легко перепроектировано. Это может пойти еще хуже, если вы будете настаивать на том, что только соседи могут обмениваться данными, и если вы решите добавить особый тип объектов для обмена между слоями вместо того, чтобы пропустить один набор объектов через несколько слоев.
Добавьте слои, которые вам нужны, чтобы вы чувствовали себя более комфортно при разработке приложения и которые обеспечили бы разумное разделение задач и удобство обслуживания, необходимые для масштаба вашего приложения. Вы можете просто сделать самое простое приложение, которое будет использоваться всего несколько недель и должно быть разработано как можно быстрее. В таком случае вы можете сделать это в течение нескольких дней, просто используя веб-формы ASP.NET и элементы управления источниками данных (или динамические данные ASP.NET). Это может быть плохо расширяемым, но в такой ситуации это именно то, что вам нужно для быстрой реализации приложения. Написание слоев и выполнение всего, что связано с ремонтопригодностью и расширяемостью, разумно, если вам это нужно. Другой метод быстрого прототипирования - ASP.NET MVC Scaffolding, который может создать быстрый многослойный каркас приложения, который может быть далее изменен.
- Оба подхода верны и зависят только от того, который вам нравится. Первый называется шаблон активной записи , но он не очень часто используется с структурой сущностей. Второй подход более популярен. Вы можете использовать EF непосредственно в каком-то среднем классе, который вы назвали
Provider (общее имя также Service). Этот класс будет выполнять как логику доступа к данным, так и бизнес-логику. В более сложных приложениях разработчикам нравится как-то оборачивать EF в отдельный класс по шаблону репозитория и вызывать репозиторий либо из службы, либо напрямую из веб-приложения. код или контроллер (в зависимости от объема бизнес-логики). Попробуйте сделать это без хранилища в первую очередь. Мое личное мнение таково, что люди должны начать использовать репозиторий только после того, как они поймут сам EF.
- Опять оба подхода верны. В простом приложении вполне приемлемо создать модель EF с классами POCO (EFv4.x) и использовать их во всех слоях. Если вы используете ASP.NET MVC, вы можете обнаружить, что вам нужны специальные классы в качестве моделей представления, чтобы полностью представить потребности ваших отдельных представлений. В более сложном приложении вы можете иметь отдельные объекты, представленные на бизнес-уровне - это особенно используется, если бизнес-уровень представлен как удаленная служба (WCF).
- Зависит от того, как вы пишете эти методы DAL - абсолютно необходимо не делить контекст EF между запросами ! Это также зависит от того, хотите ли вы написать тест или нет. Слой, определенный статическими методами, - это то, что напрямую идет в тестируемую архитектуру, где вы хотите, чтобы модульное тестирование выполнялось только в одном слое (модульное тестирование с EF может быть сложным). Это также зависит от того, хотите ли вы использовать внедрение зависимостей, основанное на экземплярах.