Комментарии 30
Спасибо, кэп.
Только вопрос — а о чем статья?
Только вопрос — а о чем статья?
> Преобразование сущностей БД в логические сущности приложения – это одна из главных обязанностей бизнес слоя.
Мимо. Это обязанность DAL`а.
А вы читали Мартина Фаулера (или Дино Эспозито для конкретно приложений на .net)? У вас очень неполное представление о том, о чем вы пишете.
Мимо. Это обязанность DAL`а.
А вы читали Мартина Фаулера (или Дино Эспозито для конкретно приложений на .net)? У вас очень неполное представление о том, о чем вы пишете.
Я так подозреваю, что имеется ввиду конвертация ентитей, полученных из DAL в сущности, которые выставляет наружу BL.
Вряд ли DAL должен иметь знания о доменной области, в котором его сущности используются.
Вряд ли DAL должен иметь знания о доменной области, в котором его сущности используются.
Должен. BLL выставляет требования к DAL и сам ни на что не ссылается — так достигается портабельность BLL. Кроме того DAL может использовать POCO из BLL для маппинга.
А вообще я привык слои называть так:
— Business,
— Resource или Infrastructure,
— Service-
— Presentation.
Или так:
— Domain
— Application
— Infrastructure
— Presentation
— Business,
— Resource или Infrastructure,
— Service-
— Presentation.
Или так:
— Domain
— Application
— Infrastructure
— Presentation
С чего бы вдруг DAL должен знать о каких-то деталях BLL?
Business объявляет интерфейсы\контракты для инфраструктуры и сам ни на что не ссылается. Инфраструктура реализует все интерфейсы, через ioc связывает их со своими реализациями и отдает навверх. Кроме того использует сущности из BLL для маппинга на дб Code first.
В качестве преимуществ такого подхода:
у нас есть ядро бизнес-логики написанное на Portable Class Library. Оно ни на что не ссылается. И есть реализация инфраструктуры для Windows 8 и Windows Phone 8 отдельно. (потому как их реализация платформозависимая).
В качестве преимуществ такого подхода:
у нас есть ядро бизнес-логики написанное на Portable Class Library. Оно ни на что не ссылается. И есть реализация инфраструктуры для Windows 8 и Windows Phone 8 отдельно. (потому как их реализация платформозависимая).
Под DAL выше имелся ввиду Data Abstraction Layer так-то.
Который абстрагирует что от чего, простите?
Который абстрагирует от конкретной СУБД.
Я же специально спросил «что». Что он абстрагирует? Что у него на выходе? Какими терминами он оперирует?
На выходе у него Data Entities.
Вас троллят тем, что в DAL, «А» — это не Abstraction, а Access.
Изложенные в каких терминах? Если БД, то какой (памятуя об абстракции)? Если домена, то почему он не знает о BL? Если промежуточные, то зачем вам еще один уровень абстракции?
Вы уверены, что стоит DAL называть инфраструктурой?
В классическом n-tier, PL -> BLL -> DAL -> Data Providers, где нижние слои ничего не знают о верхних.
А, сорри, вы о DDD. Тогда согласен. В этом случае условный DAL действительно оказывается сбоку, а доменная модель обособлена.
*в которой
Странно, что целый день поисков привел в итоге к n-tiers архитектуре, но не привел к тому же DDD, или к CQRS :-) Или к Фаулеру с его Patterns of Enterprise Application Architecture.
Этот слой встречается только в крупных приложениях. По сути это API интерфейс для доступа к приложению с других приложений. Этот слой не будет описываться, из-за моей крайней неосведомленности в этой области.
… а вот если бы вы читали уже упомянутого Фаулера или Эспозито, вы бы знали, что Service Layer (в отличие от Service Facade) находится внутри приложения, и ничего общего с API не имеет.
Знаете, я писал этот пост для людей, которые только начинают разбираться в таких тонкостях, поэтому я не считаю небольшую дезинформацию, очень уж вредной. Я конечно не говорю, что это было сделано специально, я не был достаточно осведомлен, в тех аспектах, к которым у вас возникли замечания. Также хочу сказать, что те небольшие ошибки не умаляют ценность статьи для новичков, и минусуя этот пост вы количество людей, которым она могла бы пригодиться. Всем спасибо, это мой последний комментарий к этому посту.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура приложений: взгляд ASP.NET MVC программиста