Архитектура приложений: взгляд ASP.NET MVC программиста

[@retran]

Спасибо, кэп.
Только вопрос — а о чем статья?

[@jojo97]

Об архитектуре приложений:)

[@retran]

> Преобразование сущностей БД в логические сущности приложения – это одна из главных обязанностей бизнес слоя.

Мимо. Это обязанность DAL`а.

А вы читали Мартина Фаулера (или Дино Эспозито для конкретно приложений на .net)? У вас очень неполное представление о том, о чем вы пишете.

[@PartAlex]

Я так подозреваю, что имеется ввиду конвертация ентитей, полученных из DAL в сущности, которые выставляет наружу BL.
Вряд ли DAL должен иметь знания о доменной области, в котором его сущности используются.

[@Nagg]

Должен. BLL выставляет требования к DAL и сам ни на что не ссылается — так достигается портабельность BLL. Кроме того DAL может использовать POCO из BLL для маппинга.

[@Nagg]

А вообще я привык слои называть так:
— Business,
— Resource или Infrastructure,
— Service-
— Presentation.

Или так:
— Domain
— Application
— Infrastructure
— Presentation

[@PartAlex]

С чего бы вдруг DAL должен знать о каких-то деталях BLL?

[@Nagg]

Business объявляет интерфейсы\контракты для инфраструктуры и сам ни на что не ссылается. Инфраструктура реализует все интерфейсы, через ioc связывает их со своими реализациями и отдает навверх. Кроме того использует сущности из BLL для маппинга на дб Code first.

В качестве преимуществ такого подхода:
у нас есть ядро бизнес-логики написанное на Portable Class Library. Оно ни на что не ссылается. И есть реализация инфраструктуры для Windows 8 и Windows Phone 8 отдельно. (потому как их реализация платформозависимая).

[@PartAlex]

Под DAL выше имелся ввиду Data Abstraction Layer так-то.

[@lair]

Который абстрагирует что от чего, простите?

[@PartAlex]

Который абстрагирует от конкретной СУБД.

[@lair]

Я же специально спросил «что». Что он абстрагирует? Что у него на выходе? Какими терминами он оперирует?

[@PartAlex]

На выходе у него Data Entities.

[@retran]

Вас троллят тем, что в DAL, «А» — это не Abstraction, а Access.

[@PartAlex]

Да. Data Access Layer — более правильная расшифровка того, о чём я говорю.

[@lair]

Изложенные в каких терминах? Если БД, то какой (памятуя об абстракции)? Если домена, то почему он не знает о BL? Если промежуточные, то зачем вам еще один уровень абстракции?

[@PartAlex]

Data Entities у нас как правило представляют собой сущности, отражающие структуру хранилища. Да, абстракция от конкретной субд ложится скорее на интерфейс дата провайдеров.

[@lair]

Эмм. Если у вас data entities отражают структуру хранилища, то они уже не абстрактные, а конкретные, потому что структура хранилища — это атрибут конкретной СУБД.

[@PartAlex]

Окей, я мысль понял. Снимаю шляпу и посыпаю голову пеплом.

[@deilux]

Вы уверены, что стоит DAL называть инфраструктурой?

[@mefcorvi]

В классическом n-tier, PL -> BLL -> DAL -> Data Providers, где нижние слои ничего не знают о верхних.

[@PartAlex]

Я об этом же.

[@mefcorvi]

А, сорри, вы о DDD. Тогда согласен. В этом случае условный DAL действительно оказывается сбоку, а доменная модель обособлена.

[@PartAlex]

*в которой

[@mefcorvi]

Странно, что целый день поисков привел в итоге к n-tiers архитектуре, но не привел к тому же DDD, или к CQRS :-) Или к Фаулеру с его Patterns of Enterprise Application Architecture.

[@Nagg]

Фаулера за день не прочитаешь. Но всё же +1 к DDD Layers

[@lair]

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

… а вот если бы вы читали уже упомянутого Фаулера или Эспозито, вы бы знали, что Service Layer (в отличие от Service Facade) находится внутри приложения, и ничего общего с API не имеет.

[@jojo97]

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

[@lair]

поэтому я не считаю небольшую дезинформацию, очень уж вредной

А зря. Потому что как раз людей, которые не разбираются, обманывать не стоит — у них формируются некорректные представления, с которыми потом приходится бороться.

Ну и да, не надо писать статью, не разбираясь в предмете.

[@deilux]

Вечером, после тяжелого рабочего понедельника — можно ;-)