Здравствуйте, testarch, Вы писали:
T>Подскажите насколько правильно/не правильно обращаться бизнеслогике приложения из сущности.
бизнес-логика и бизнес-сущности это единое целое — модель предметной области.
Поищите по форуму про Rich Domain Model и Anemic Domain Model.
Если у вас в сущность есть бизнес метод, то почему сущность не может его вызвать?
Re[2]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, Blazkowicz, Вы писали:
B>бизнес-логика и бизнес-сущности это единое целое — модель предметной области.
Смотря что вы понимаете под предметной областью. Если предметная область вашего приложения — то да. Если предметная область заказчика — то, очевидно, нет.
Сваливание логики и данных в одну кучу приводит к прогибанию структуры данных под текущие требования. Поддерживать получившееся месиво — занятие крайне неблагодарное.
B>Поищите по форуму про Rich Domain Model и Anemic Domain Model. B>Если у вас в сущность есть бизнес метод, то почему сущность не может его вызвать?
1. Модель данных должна быть пассивной. Разумеется, это не означает что данные не могут автоматом проверять ограничения.
2. Данные должны быть отделены от бизнес-логики.
Re[3]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, Sinix, Вы писали:
B>>бизнес-логика и бизнес-сущности это единое целое — модель предметной области. S>Смотря что вы понимаете под предметной областью. Если предметная область вашего приложения — то да. Если предметная область заказчика — то, очевидно, нет.
Бред какой-то. Приложение строится на основме МОДЕЛИ предметной области. При чем здесь какой-то асбстрактный "заказчик"? Это есть сущность финансовых отношений, а не разработки систем.
S>Сваливание логики и данных в одну кучу приводит к прогибанию структуры данных под текущие требования. Поддерживать получившееся месиво — занятие крайне неблагодарное.
Месиво получается у тех кто бросается в крайности.
S>1. Модель данных должна быть пассивной. Разумеется, это не означает что данные не могут автоматом проверять ограничения.
Существуют разные подходы и в разных ситуациях они имееют право на жизнь. Выносить логику полностью построеную исключительно на свойсвах объекта за пределы этого объекта безсмысленно.
S>2. Данные должны быть отделены от бизнес-логики.
Данные не могут быть от неё отделены по ряду причин. Они без неё никому не нужны.
Re[4]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, Blazkowicz, Вы писали:
B>Приложение строится на основме МОДЕЛИ предметной области.
Приложение строится на основе решаемых задач.
S>>Сваливание логики и данных в одну кучу приводит к прогибанию структуры данных под текущие требования. Поддерживать получившееся месиво — занятие крайне неблагодарное. B>Месиво получается у тех кто бросается в крайности.
Рассмотрим пример.
Есть класс A, который содержит некоторые данные описывающие предметную область, и метод B, реализующий некоторую функцию.
Функция в свою очередь обращается к другим данным (когда не обращается — нам неинтересно). То есть в A должна быть ссылка на DAL, tesability идет лесом и получается каша.
Aggregate и выделение root_ов скажете вы, а я скажу что в разных сценариях могут разные объекты оказаться рутами. Lazy Load не спасет, так как заменяет явную ссылку на неявную, при этом порождая SELECT N+1 проблемы.
CQRS скажете вы, но это очень тяжелая концепция для вывода "списка заказов".
Единственное что спасает с небольшими затратами — это явная загрузка связанных сущностей, но тогда по причинам того же testability метод B надо вынести из сущности A, и грузить данные внутри B.
S>>1. Модель данных должна быть пассивной. Разумеется, это не означает что данные не могут автоматом проверять ограничения. B>Существуют разные подходы и в разных ситуациях они имееют право на жизнь.
Не все, некоторые подходы, несмотря на то что они массово разрекламированы, приводят к огромным трудозатратам без наблюдаемого эффекта.
B>Выносить логику полностью построеную исключительно на свойсвах объекта за пределы этого объекта безсмысленно.
Почему же? Вынося логику у нас появляется возможность изменять и расширять методы БЛ, не трогая данные. Подсовывать динамически разные методы, переиспользовать модель данных или её части в других приложениях. Реализовывать БЛ на языке отличном, от языка реализации модели данных и Data Access.
S>>2. Данные должны быть отделены от бизнес-логики. B>Данные не могут быть от неё отделены по ряду причин. Они без неё никому не нужны.
Данные могут понадобится другой БЛ, возможно той, о которой вы не знаете еще.
Re: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, testarch, Вы писали:
T>Подскажите насколько правильно/не правильно обращаться бизнеслогике приложения из сущности.
я в текущем приложении делал вызовы классов бизнес логики только для одной цели
построение виртуальных relations между классами моделей
почему бы не перенести эти методы в сами классы моделей?
дело в том, что это виртуальные relations нужны только в этих самых компонентах бизнес логики и нигде больше
а снаружи к классу модели прилепить их не получалось
в другом приложении прогресс бар вызывал в классе, который напрямую с файловой системой общался
в целом ответ на ваш вопрос
можно, но крайне осторожно, тщательно комментируя все такие места
такого очень грязного кода в реальном приложении не избежать, но надо все контролировать, чтобы он был не более 1%-5% от всего кода приложения
общий объем грязного и грязноватого кода должен быть не более 15%
вводите для себя день (или 3 дня) рефакторинга — один раз в месяц
иначе система быстро рухнет и утонет в фекалиях
Re[2]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, Blazkowicz, Вы писали:
B>Поищите по форуму про Rich Domain Model и Anemic Domain Model.
Интересно, может с той поры (тема-то давно обсуждалась) соотношение сторонников богатой или вялой модели изменилось.
Но в общем согласен, что обе модели имеют право на жизнь.
Re[4]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, Blazkowicz, Вы писали:
B>Бред какой-то. Приложение строится на основме МОДЕЛИ предметной области. При чем здесь какой-то асбстрактный "заказчик"? Это есть сущность финансовых отношений, а не разработки систем.
Ок. Попробуем ещё раз. Вы под предметной областью понимаете сам автоматизируемый бизнес, или предметную область бизнеса? Если второе, как можно догадаться исходя из "Это есть сущность финансовых отношений" — зачем валить в одну чучу особенности предметной области бизнеса (очевидно, эти особенности от заказчика не зависят) и особенности бизнес-логики (которые определяются набором текущих требований, которые, в свою очередь, покрывают только часть бизнеса заказчика)?
Самое смешное, что с вами несогласны и я, и ув. gandjustas, придерживающийся противоположной точки зрения на разработку.
S>>1. Модель данных должна быть пассивной. Разумеется, это не означает что данные не могут автоматом проверять ограничения. B>Существуют разные подходы и в разных ситуациях они имееют право на жизнь. Выносить логику полностью построеную исключительно на свойсвах объекта за пределы этого объекта безсмысленно.
Это _сейчас_ ваш код оперирует данными только одного объекта. Появится новое требование — и всё изменится. Вы же не собираетесь ограничивать требования по принципу "вот это мы делать не будем — нам неудобно"?
S>>2. Данные должны быть отделены от бизнес-логики. B>Данные не могут быть от неё отделены по ряду причин. Они без неё никому не нужны.
Мечты-мечты — данные куда важнее любой системы. Последнюю всегда можно заменить (если, конечно, внутри не ад, содом и гоморра, и этот кошмар не просочился в модель данных).
Re[5]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, gandjustas, Вы писали:
G>Есть класс A, который содержит некоторые данные описывающие предметную область, и метод B, реализующий некоторую функцию. G>Функция в свою очередь обращается к другим данным (когда не обращается — нам неинтересно). То есть в A должна быть ссылка на DAL, tesability идет лесом и получается каша.
Это сферический коник
Re[5]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, Sinix, Вы писали:
S>Ок. Попробуем ещё раз. Вы под предметной областью понимаете сам автоматизируемый бизнес, или предметную область бизнеса? Если второе, как можно догадаться исходя из "Это есть сущность финансовых отношений" — зачем валить в одну чучу особенности предметной области бизнеса (очевидно, эти особенности от заказчика не зависят) и особенности бизнес-логики (которые определяются набором текущих требований, которые, в свою очередь, покрывают только часть бизнеса заказчика)?
Предметная область есть у задачи Если посмотреть отсюда, то видно, что твое разделение сильно надуманое. Граница есть, но она нечеткая.
Часть функционала может измениться. Часть функционала — сильно вряд ли. Часть функционала имеет много зависимостей, часть функционала имеет мало зависимостей.
Вот эта разница и дает основания помещать методы в сущности или в сервисы или еще куда.
Хочешь понять эту разницу — надо разбираться с конкретной предметной областью. На примерах вроде "у класса A есть метод B" можно заехать куда угодно.
Re[6]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, Ikemefula, Вы писали:
I>Предметная область есть у задачи Если посмотреть отсюда, то видно, что твое разделение сильно надуманое. Граница есть, но она нечеткая.
И вам тоже здрваствуйте. Мы с вами буквально неделю назад обсуждали эту тему в три круга. Сегодня вы начинаете с того же — игнорируете мои доводы и даёте свои определения, без какого-либо доводов с вашей стороны. Пардон, но спорить впустую я не буду. ?
Re[7]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Ikemefula, Вы писали:
I>>Предметная область есть у задачи Если посмотреть отсюда, то видно, что твое разделение сильно надуманое. Граница есть, но она нечеткая.
S>И вам тоже здрваствуйте. Мы с вами буквально неделю назад обсуждали эту тему в три круга. Сегодня вы начинаете с того же — игнорируете мои доводы и даёте свои определения, без какого-либо доводов с вашей стороны.
Я дал свои определения. А вот твоих так и не получил, т.е. вообще
Re[8]: Обращение к бизнеслогике приложения из сущности.
S>я писал для вас зря — тем более нет никакого смысла продолжать.
А я помнится написал тебе, что той разницы, которую ты хочешь видеть, просто нет
Ты так и не обозначил правило, благодаря которому можно ввести твое разделение.
Между тем я более чем явно сделал это за тебя.
Все достаточно просто. Еет тех двух подходов к моделированию которые ты хочешь видеть. Твой подход N1 относится где к бизнес логистике, второй- ко всем остальным областям
Re[6]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, Ikemefula, Вы писали:
I>Хочешь понять эту разницу — надо разбираться с конкретной предметной областью. На примерах вроде "у класса A есть метод B" можно заехать куда угодно.
Подставь любую предметную область в указанный мной абстрактный пример и ты получишь одни и те же проблемы.
Кроме предметной области в любом её понимании есть вполне технические проблемы и принципы Data != Objects, SRP, принцип расслоения итп.
Re[7]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, gandjustas, Вы писали:
I>>Хочешь понять эту разницу — надо разбираться с конкретной предметной областью. На примерах вроде "у класса A есть метод B" можно заехать куда угодно.
G>Подставь любую предметную область в указанный мной абстрактный пример и ты получишь одни и те же проблемы.
В том то и дело, что не получается, ибо пример у тебя слишком общий а хоть как то конкретизировать ты не можешь
Re[8]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Хочешь понять эту разницу — надо разбираться с конкретной предметной областью. На примерах вроде "у класса A есть метод B" можно заехать куда угодно.
G>>Подставь любую предметную область в указанный мной абстрактный пример и ты получишь одни и те же проблемы.
I>В том то и дело, что не получается, ибо пример у тебя слишком общий а хоть как то конкретизировать ты не можешь
Еще раз: подставь любые сущности. Условие: Метод сущности X должен обращаться к связанной сущности Y, а еще лучше к коллекции Y.
Ты получишь абсолютно одинаковые проблемы, независимо от X и Y.
Re[9]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, gandjustas, Вы писали:
G>Еще раз: подставь любые сущности. Условие: Метод сущности X должен обращаться к связанной сущности Y, а еще лучше к коллекции Y. G>Ты получишь абсолютно одинаковые проблемы, независимо от X и Y.
Чушь. Я вот как ни кручу, у меня не получается ссылки на dal как ты расписывал
Re[10]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>Еще раз: подставь любые сущности. Условие: Метод сущности X должен обращаться к связанной сущности Y, а еще лучше к коллекции Y. G>>Ты получишь абсолютно одинаковые проблемы, независимо от X и Y.
I>Чушь. Я вот как ни кручу, у меня не получается ссылки на dal как ты расписывал
Show Me The Code. Я тебе покажу ссылку.
Re[11]: Обращение к бизнеслогике приложения из сущности.
Здравствуйте, gandjustas, Вы писали:
I>>Чушь. Я вот как ни кручу, у меня не получается ссылки на dal как ты расписывал
G>Show Me The Code. Я тебе покажу ссылку.
?
