Вот к примеру есть обычное приложение web asp.net mvc которое работает с базой.
Из контроллера вызывается метод репозитория. Далее из метода репозитория вызывается метод EF контекста.

Я правильно понимаю, что DAL — это EF контекст, а BusinessLayer — это репозиторий?

Здравствуйте, merge, Вы писали:

M>Вот к примеру есть обычное приложение web asp.net mvc которое работает с базой.
M>Из контроллера вызывается метод репозитория. Далее из метода репозитория вызывается метод EF контекста.

M>Я правильно понимаю, что DAL — это EF контекст, а BusinessLayer — это репозиторий?

У меня, например, такие сущности как UserRepository и EntityRepository находятся
в сборке Dal. Там же находится ORM модель (контекст). Т.е. всякие репозитории
потребляют Dal, и, в свою очередь, потребляются BL.

Здравствуйте, merge, Вы писали:

M>Вот к примеру есть обычное приложение web asp.net mvc которое работает с базой.
M>Из контроллера вызывается метод репозитория. Далее из метода репозитория вызывается метод EF контекста.

M>Я правильно понимаю, что DAL — это EF контекст, а BusinessLayer — это репозиторий?

неправильно, и вообще забудь эти слова, только путаться будешь.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, merge, Вы писали:

M>>Вот к примеру есть обычное приложение web asp.net mvc которое работает с базой.
M>>Из контроллера вызывается метод репозитория. Далее из метода репозитория вызывается метод EF контекста.

M>>Я правильно понимаю, что DAL — это EF контекст, а BusinessLayer — это репозиторий?

G>неправильно, и вообще забудь эти слова, только путаться будешь.

ну так рассказал бы. а то все зачеркнул, и ничего не предложил

Здравствуйте, merge, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, merge, Вы писали:

M>>>Вот к примеру есть обычное приложение web asp.net mvc которое работает с базой.
M>>>Из контроллера вызывается метод репозитория. Далее из метода репозитория вызывается метод EF контекста.

M>>>Я правильно понимаю, что DAL — это EF контекст, а BusinessLayer — это репозиторий?

G>>неправильно, и вообще забудь эти слова, только путаться будешь.

M>ну так рассказал бы. а то все зачеркнул, и ничего не предложил

Технологии влияют на архитектуру. Когда придумывали DAL и BL были другие технологии, попытка натянуть эти понятия на архитектуру приложения сегодня вызовет увеличение сложности. А попытка объяснить — обязательно вызовет холивар.

Здравствуйте, gandjustas, Вы писали:

G>Технологии влияют на архитектуру. Когда придумывали DAL и BL были другие технологии, попытка натянуть эти понятия на архитектуру приложения сегодня вызовет увеличение сложности. А попытка объяснить — обязательно вызовет холивар.

...причём не относящийся к исходному вопросу, а про то, чья архитектура истиннее.

Здравствуйте, merge, Вы писали:

M>Я правильно понимаю, что DAL — это EF контекст, а BusinessLayer — это репозиторий?

Очень не люблю термин "Business Layer". Предполагается, что это средоточие бизнес логики и бизнес логика суть только в этом слое.

А, вот, если у нас много хранимых процедур, то где бизнес слой, в данных? А если это у нас еще и SPA, и общую сумму заказа на клиенте считаем, то бизнес слой где, на клиенте? А как же хранимые процедуры?
Или, вот, GMail. Какая из его частей более бизнес?

Отвратительный термин, в общем, не годный.

Здравствуйте, merge, Вы писали:

M>Я правильно понимаю, что DAL — это EF контекст, а BusinessLayer — это репозиторий?

DAL это EF, только не контекст, а сам фреймворк. Репозитарий не нужен, работайте с EF напрямую везде где нужен доступ к данным.

Здравствуйте, Kudriako, Вы писали:

K>Очень не люблю термин "Business Layer". Предполагается, что это средоточие бизнес логики и бизнес логика суть только в этом слое.

Да.

K>А, вот, если у нас много хранимых процедур, то где бизнес слой, в данных? А если это у нас еще и SPA, и общую сумму заказа на клиенте считаем, то бизнес слой где, на клиенте? А как же хранимые процедуры?

Это значит слой размазан. Обычно это антипаттерн (как и хранимые процедуры).

K>Или, вот, GMail. Какая из его частей более бизнес?

Есть клиент, есть сервер. Бизнес логика есть и там и там. Что из них более "бизнес" — совершенно бессмысленный вопрос. Если подняться на высоту птичьего полета, то все, что на клиенте это слой презентационной логика. Но рассматривая архитектуру самого клиента, можно увидеть свои слои, среди которых можно обозначить и свой BL, и свой PL, и свой DAL.

K>Отвратительный термин, в общем, не годный.

Нормальный термин. Приложение разбивают на слои, чтобы проще было его поддерживать. Чем меньше кода в слое, тем легче это делать. Для начала выделим слой доступа к данным. Сейчас его никто не пишет руками, используют готовые ORM (если данные в БД), идеальный вариант слоя, берем уже готовый фреймворк, ноль нашего кода, поддержкой его занимается кто-то другой. Потом выделим презентационный слой. Потом код, отвечающий за какие-то протоколы, форматы взаимодействия, ввод-вывод. Чем больше разных слоев мы выделим, тем лучше мы изолируем оставшийся код приложения. Этот слой тоже надо как-то называть, BL подходящий термин.

Надо понимать, что разделение на слои это не какая-то догма, а лишь способ снизить издержки. В каждом конкретном случае надо понимать, что дешевле, изоляция или размазывание, это не всегда очевидно, зато здесь широкое поле для священных войн.

Здравствуйте, Ziaw, Вы писали:

K>>А, вот, если у нас много хранимых процедур, то где бизнес слой, в данных? А если это у нас еще и SPA, и общую сумму заказа на клиенте считаем, то бизнес слой где, на клиенте? А как же хранимые процедуры?
Z>Это значит слой размазан.

Не значит. Размазана логика а не слой. А слой либо есть, и тогда это именно слой а не размазня, либо его нету.

Z>Чем больше разных слоев мы выделим, тем лучше мы изолируем оставшийся код приложения.

Это слишком смелое утверждение.

Здравствуйте, AndrewVK, Вы писали:

Z>>Это значит слой размазан.
AVK>Не значит. Размазана логика а не слой. А слой либо есть, и тогда это именно слой а не размазня, либо его нету.

Слой размазан это и есть размазня. Не надо докапываться до слов.

Z>>Чем больше разных слоев мы выделим, тем лучше мы изолируем оставшийся код приложения.
AVK>Это слишком смелое утверждение.

Когда я писал — понимал, что на каждое утверждение можно найти контрпримеры. Конкретно это намеренно оставлено провокационным, но доносящим общую мысль.

Здравствуйте, Ziaw, Вы писали:

Z>Слой размазан это и есть размазня. Не надо докапываться до слов.

В данном с лучае надо. Когда говорят о слое, то имеют в виду вполне определенную архитектуру, а не вообще что угодно. Иначе, с таким подходом как у тебя, слои можно найти вообще в любом приложении. Только практической ценности в нем примерно столько же, сколько в ad hoc гипотезах.

Z>>>Чем больше разных слоев мы выделим, тем лучше мы изолируем оставшийся код приложения.
AVK>>Это слишком смелое утверждение.
Z>Когда я писал — понимал, что на каждое утверждение можно найти контрпримеры.

То что ты понимал это здорово, но написанное звучит уж очень категорично и безапелляционно.

Здравствуйте, AndrewVK, Вы писали:

AVK>В данном с лучае надо. Когда говорят о слое, то имеют в виду вполне определенную архитектуру, а не вообще что угодно. Иначе, с таким подходом как у тебя, слои можно найти вообще в любом приложении. Только практической ценности в нем примерно столько же, сколько в ad hoc гипотезах.

Ок, претензию понял. Код логики размазан, вместо выделения в отдельный слой. Но тут тоже можно начинать придираться. Например когда часть логики вынесена в хранимые процедуры, слой все равно есть, просто часть слоя ушла на сервер БД. Эти придирки и послужили причиной написания поста. Слой перестает быть слоем лишь в том случае, когда у программиста начинаются сложности с проведением границы между кодом который является бизнес логикой и кодом, который ей не является.

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

AVK>То что ты понимал это здорово, но написанное звучит уж очень категорично и безапелляционно.

Да и пусть. Если не занудствовать, то так оно и есть. Это самое простое определение бизнес логики, которое у меня получилось. Если у человека не получается понять, что же такое бизнес логика — легче начать от обратного. Выделить то, что ей точно не является, для начала — DAL и PL.

Здравствуйте, Ziaw, Вы писали:

Z>Да и пусть. Если не занудствовать, то так оно и есть. Это самое простое определение бизнес логики

Похоже ты продолжаешь путать пониятие бизнес логики и слоя бизнес логики. Это не одно и тоже.

Здравствуйте, Ziaw, Вы писали:

Z>Обычно это антипаттерн (как и хранимые процедуры).

А разбработчики баз данных то и не знают.

Z>Это значит слой размазан.

В хорошем приложении обычно есть слои либо высокоуровневые абстракции, согласен, и каждый слой / абстракция несет в себе бизнес логику либо обеспечивает ее работу.
Если нечто не несет бизнес-логику и не обеспечивает ее работу, то это можно / нужно убрать из приложения как ненужное.

Здравствуйте, AndrewVK, Вы писали:

Z>>Да и пусть. Если не занудствовать, то так оно и есть. Это самое простое определение бизнес логики
AVK>Похоже ты продолжаешь путать пониятие бизнес логики и слоя бизнес логики. Это не одно и тоже.

Или ты фигурно режешь по цитатам.

Здравствуйте, Kudriako, Вы писали:

Z>>Обычно это антипаттерн (как и хранимые процедуры).
K>А разбработчики баз данных то и не знают.

Знают. Но похоже не все.

K>В хорошем приложении обычно есть слои либо высокоуровневые абстракции, согласен, и каждый слой / абстракция несет в себе бизнес логику либо обеспечивает ее работу.

И этот человек согласен с тем, что я тут путаю слой и логику.

K>Если нечто не несет бизнес-логику и не обеспечивает ее работу, то это можно / нужно убрать из приложения как ненужное.

Играем в КО?

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, merge, Вы писали:

M>>Я правильно понимаю, что DAL — это EF контекст, а BusinessLayer — это репозиторий?

Z>DAL это EF, только не контекст, а сам фреймворк. Репозитарий не нужен, работайте с EF напрямую везде где нужен доступ к данным.

заменить репозиторий на "инициализировать контекст EF в конструкторе контроллера"? это я к тому что если надо вызвать 2 метода (транзакция) в одном запросе, как быть?

Здравствуйте, merge, Вы писали:

M>заменить репозиторий на "инициализировать контекст EF в конструкторе контроллера"? это я к тому что если надо вызвать 2 метода (транзакция) в одном запросе, как быть?

В конструкторе неудобно, освобождать его где? Можно делать using (new Context) прямо в экшене и управлять транзакцией явно. Для большинства запросов достаточно создавать один контекст и одну транзакцию на запрос в фильтрах. Если недостаточно — транзакция в БД это самая настоящая бизнес логика, не надо бояться управлять ей явно, не надо пытаться спрятать ее за какие-то абстракции.

Здравствуйте, merge, Вы писали:

M>Я правильно понимаю, что DAL — это EF контекст, а BusinessLayer — это репозиторий?

Я предпочитаю рассматривать слои с точки зрения разделения ответственности.

На примерах:
* Если у вас есть гора однотипного кода, отвечающего за получение-отправку данных, то это, очевидно, DAL. Если код спрятан в инфраструктуру (тот же EF/BLToolkit) — DAL в чистом виде может и не быть, или он может ограничиться классами с настройками провайдера данных.

* В свою очередь, BL — это код, который решает задачи клиента путём вызова "кирпичиков" из прочих слоёв. Вполне возможно, что кирпичиков как таковых может и не быть, или наоборот, весь бизнес-код — это сборка готовых полуфабрикатов.

Главное, что каждый слой решает свой круг задач: бизнес-код не должен бороться с инфраструктурой и детально настраивать логирование; DAL не должен мигать индикатором на форме или поздравлять пользователя с днём рождения.
Основной смысл подобного разделения — удержание сложности сопровождения проекта в разумных рамках. Если какой-то функционал изолирован, то правки-тестирование будут локальны и не займут много ресурсов. Обратный пример, когда логика раскидана по всему проекту, думаю, объяснять не надо: каждый сталкивался

Ну и само разделение — DAL/логика/UI/... сложилось исторически, т.к. проблемы-исправления в каждом из слоёв как правило весьма специфические и редко влияют на соседей.