[quote invm]KellyLynch"А каким образом, при бизнес-логике на клиенте, будет обеспечиваться согласованность данных?"
Транзакции ещё никто не отменял, в т.ч. и из под Entity Framework

[quote Yuri Abele]invmKellyLynch"А каким образом, при бизнес-логике на клиенте, будет обеспечиваться согласованность данных?"
Транзакции ещё никто не отменял, в т.ч. и из под Entity Framework
Я про уточнение, что речь об Application Server.

Ролг Хупин,

ну не совсем согласен. Если вопрос разовых расходов не стоит, то IMHO, вынос бизнес логики в базу данных только тогда оправдан, когда очень очень критична производительность.
Да и то, тут смотря как делать, многое наоборот в Application Server быстрее работать будет.
А многое на уровне базы данных вообще не корректно держать - я про то, когда сервер базы данных куда-то к внешним сервисам лезет (Big Data - особый случай).

Но это всё о том, как корректно с точки зрения архитектуры и separation of concerns

Владислав КолосовYuri Abele,
собственно, решение принимается из принципа экономии ресурсов - объёма кода, зарплаты, оборудования и так далее по списку.
Вы не автор топика, как и я впрочем, поэтому ему решать.
Лично я, если начальство дает денег (а начальство, кстати, не всегда дураки и иногда, удивительно, но требуют правильных вещей), воспользовался бы этим и переделал все под правильную архитектуру с разделением на уровни абстракции, масштабированием и т.д..

invmYuri AbeleДа и то, тут смотря как делать, многое наоборот в Application Server быстрее работать будет.Конкретный пример есть? При условии, что для проверки БЛ нужны только данные, находящиеся в БД.
Ну, во первых, совсем не маловажное ограничение.
А так - какие-то сложные математические вычисления (например custom шифрация), до некоторых пор работа с JSON была проболемой (с 2016 стало совсем хорошо), обработка изображений сохранённых в базе. И т.д..

Есть и задачи, для которых использование DB Engine единственно правильное. Подсчеты статистик по реляционным таблицам, например.

---------------------------

Можно долго дискутировать, но, как-то так получается (блин, чуствую себя динозавром!), с годами, что вот такое разделение всеми воспринимается, как правильное.
Я консалтером работаю, т.е. проекты и клиенты постоянно меняются, и часто бывают миграционные проекты, и всегда речь о разнесениях "что-где" так как выше упоминал. А вот задач обратного порядка уже даже и не помню.

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

Мне к клиенту бежать. Сегодня точно больше дискуссию не поддержу.
Да и вообще, мы IMHO в off-topic скатываемся. Автор не против?

Удалось раньше сбежать :-)

Превентивный P.S. Я ни в коем случае не ставлю целью рисануться и кого-то куда-то тыркнуть - уже давно этим не болею. По той же причине ("давно") все священные войны считаю безсмысленными - нет плохих продуктов и платформ, но есть плохие решения на их базе.

---------------------

Критерии правильности? Я мог бы порыться в интернете. Там куча статей о том как надо и не надо.
Но вот из моего личного опыта (это как в армии - устав кажется дурацким, но там каждое слово писано кровью :-))
жесткое разделение/абстагирование слоев ( separation of concerns )

KISS и DRY принципы

осознание того, что и так дохрена сложностей накопится, что не надо:
- выбирать "крутые" решения вместо легко сопроваждаемых - яркий пример,
это вечный спор использовать ли графический ETL инструмент или круто написать все скриптами?
- выбирать дорогие решения, потому что они закрывают 120% пожеланий, а остановиться на простых и интуитивных решениях, пусть они процентов 90 закроют

не надо писать custom логику там, где есть готовые, пусть и не идеальные решения. Например:
- да, custom скриптами и хранимыми процедурами можно достичь большей производительности, никто и не спорит, но объектно-ориентированность при этом теряется. И тут лучше взять OR-MAPPER (Entity Framework например)

Типичное решение, которое у немцев считается "правильным":
SPA (Single Page Application), где

FE (Frontend) - Чисто клиентское MVC решение (Angular например)

FE "дёргает" API из BE (Backend)

Сам BE состоит из отдельных проектов/библиотек для
- DAL (Data Access Layer) - в нем, собственно, и сидит бизнеслогика
- DAL через EF (Entity Framework) обращается к DB (Database)
- в DB все таблицы разделены по "бизнес группам" - собственным схемам. Ни в коем случае не использовать dbo схему (мы про MSSQL)
- в DAL все данные описаны POCO моделями 1:1 заMAPленными на таблицы
- с другого конца, на "входе" сидит API (ASP.NET WebAPI например), которы всего лишь мостик между DAL и FE
- обмен данными между FE и API по протоколу REST (проще всего в JSON, но можно и другие форматеры). Можно и SOAP, но это уже не KISS
- c FEом API общается сериализованными ViewModels . Конвертация между Model и ViewModel происходит через специальные MAPперы. Есть готовые, которые деклаларитвно описывают взаимный MAPпинг.
- во FE идеально тоже использовать объектноориентированность и разделение на уровни логики (специально не хотел упоминать MVC, MVVM и т.п.) - Angular идеально подходит.

-----

К чему приводит такой подход, что он позволяет?
- в больших проектах четко разделить работу по отдельным сотрудникам - один DBA, другой DBD, третий UX/UI дизайнер, 4й BE програмист, один архитектор на всех и Agile Coach (наприме SCRUM мастер).
- Project Management это отдельная песня, тоже можно поговорить, но отдельно. Скажу только пару фраз:
1. абсолютный SPOT (Single Point off Truth / Single Source off Truth)
2. жесткое разбиение на SPRINTы

Т.е., к примеру
- класический ASP.NET вообще даже не рассматривается.
- ASP.NET MVC - менее, но всё же тоже не желателен
- какие-то custom JavaScript решения для FE - не желательны (лучше исходники в Type Script и еще лучше декларативный MVC типа Angular, менее желателен Spagetty Code как в React, хотя он и активно с Angular конкурирует)

И т.д. и т.д.. Надеюсь был понят и кому-то помог :-)

Забыл - немцы ещё очень сильно Unit Test-ы любят, в т.ч. и во FrontEnd-е