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

S>Здравствуйте, Nikita Lyapin, Вы писали:

NL>>По большому счету Фаулер все написал, но я взял на себя смелость его дополнить. Я прав? Или ошибаюсь? Хотелось бы обсудить с сообществом.
S>Фаулер устарел на 20 лет. Прямо в этом же форуме уже были подробные обсуждения его заблуждений. Коротко о главном:
S>1. Transaction Script у Фаулера почему-то прибит гвоздями к процедурному подходу. Даже двадцать лет назад ничто не мешало порождать скрипт объектно-ориентированным способом.
S>Это сразу же убирает обозначенные Фаулером недостатки.

Парадигмы не устаревают. Вы можете использовать все самые новомодные библиотеки, но при этом хорошо бы озадачиться вопросом в какой парадигме вы пишете. Если вы пишите на ООП языке вроде C# и при этом у вас везде static методы да и только — у вас не используется парадигма ООП. Дело в том, что фреймворки и ОРМ по своей природе накладывают ограничения на то как их можно использовать.

S>2. В современном .Net есть нормальные ORM, которые позволяют вообще не считать код по обмену данными между базой и приложением частью приложения. В Java тоже всё гораздо лучше, чем во времена Фаулера, хотя и отстаёт на одно-два поколения от linq2db.
Linq2Db занял свою нишу. Это типизированный SQL по факту. Рассуждать о том, что хранимые процедуры больше относятся к ООП, чем к процедурам. Ну странно как-то... Ведь разница между хранимой процедурой и кодом на Linq2Db в сущности только в типизации и все...

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