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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Z>А описал я практический алгоритм определения какой код является бизнес-логикой и способ выделить его в отдельный слой.

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

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

Z>Это значит слой размазан. Обычно это антипаттерн (как и хранимые процедуры).
Есть много интересных исключений, когда ни то ни другое не является антипаттерном.
Например, я не вижу никакого смысла запрещать проводить предварительную валидацию введённых данных на клиенте — пусть даже и тонком. Требование всегда делегировать полномочия по валидации серверу под предлогом "ему лучше знать" негативно влияет на user experience, то есть является контрпродуктивным.
Далее, я не вижу ничего плохого в полном переносе всей "бизнес-логики" внутрь СУБД в виде набора хранимых процедур. Антипаттерном является произвольное смешивание подходов "среднего слоя" с хранимыми процедурами. Самое абсурдное, что я когда-либо видел — это хранимки для CRUD, поверх которых работает DAL.

Вот к примеру есть обычное приложение 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.

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

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

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

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

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

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

Здравствуйте, 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 подходящий термин.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Играем в КО?

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

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

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

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

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

Здравствуйте, Ziaw, Вы писали:
Z>В конструкторе неудобно, освобождать его где?
DI контейнер освободит...

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

Z>>В конструкторе неудобно, освобождать его где?
QL>DI контейнер освободит...

Если в проект уже притащили DI контейнер и научили его создавать контроллеры — это тоже вариант. Но это лишь частный случай.

Здравствуйте, Ziaw, Вы писали:
Z>Но это лишь частный случай.

Контроллер реализует IDisposable — освободить можно переопределив Dispose().

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

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

Я шота твой подход никак понять не могу и выяснить ,что же ты называешь бизнеслогикой — тоже не могу. Бизнеслогика есть всегда, а слоёв может и не быть. Как быть ?

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

I>Я шота твой подход никак понять не могу и выяснить ,что же ты называешь бизнеслогикой — тоже не могу. Бизнеслогика есть всегда, а слоёв может и не быть. Как быть ?

Как быть с чем? С тем, что в твоем ПО есть бизнеслогика предлагаю ничего не делать. Это хороший знак. С тем, что в принципе слоев может не быть тоже ничего делать не надо, это просто факт.

А описал я практический алгоритм определения какой код является бизнес-логикой и способ выделить его в отдельный слой. У вопрошающего, если я правильно понял его терзания, были проблемы с этим. Если не получается найти отличительные особенности бизнес логики, то можно пойти от противного, это может получиться быстрее.

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

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

QL>Контроллер реализует IDisposable — освободить можно переопределив Dispose().

Можно. Но все же я бы привязывал время жизни контекста/транзакции к запросу, а не ко времени жизни контроллера. Даже если сейчас они совпадают и вероятность того, что перестанут минимальна.

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

S>Например, я не вижу никакого смысла запрещать проводить предварительную валидацию введённых данных на клиенте — пусть даже и тонком. Требование всегда делегировать полномочия по валидации серверу под предлогом "ему лучше знать" негативно влияет на user experience, то есть является контрпродуктивным.

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

S>Далее, я не вижу ничего плохого в полном переносе всей "бизнес-логики" внутрь СУБД в виде набора хранимых процедур.

А тут не очень. Я вижу очень много плохого и могу принять такой подход только когда сервер отсутствует и его роль должна играть сама БД. Но все равно куча минусов остается. Главные минусы — неудобный язык, ужасные средства разработки, отладки, тестирования. Если же какой-то сервер есть, то в него все равно начнет просачиваться логика и мы получим два сервера с логикой, а в отличии от клиента это никаким UE не оправдано.

S>Антипаттерном является произвольное смешивание подходов "среднего слоя" с хранимыми процедурами. Самое абсурдное, что я когда-либо видел — это хранимки для CRUD, поверх которых работает DAL.

+1. Это шедевр, причем далеко не единичный.