Обращение к бизнеслогике приложения из сущности.
От: testarch  
Дата: 22.12.10 14:15
Оценка:
Подскажите насколько правильно/не правильно обращаться бизнеслогике приложения из сущности.
Re: Обращение к бизнеслогике приложения из сущности.
От: Blazkowicz Россия  
Дата: 22.12.10 14:21
Оценка: 1 (1) +1 -1
Здравствуйте, testarch, Вы писали:

T>Подскажите насколько правильно/не правильно обращаться бизнеслогике приложения из сущности.

бизнес-логика и бизнес-сущности это единое целое — модель предметной области.
Поищите по форуму про Rich Domain Model и Anemic Domain Model.
Если у вас в сущность есть бизнес метод, то почему сущность не может его вызвать?
Re[2]: Обращение к бизнеслогике приложения из сущности.
От: Sinix  
Дата: 22.12.10 16:53
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

B>бизнес-логика и бизнес-сущности это единое целое — модель предметной области.

Смотря что вы понимаете под предметной областью. Если предметная область вашего приложения — то да. Если предметная область заказчика — то, очевидно, нет.

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

B>Поищите по форуму про Rich Domain Model и Anemic Domain Model.

B>Если у вас в сущность есть бизнес метод, то почему сущность не может его вызвать?
1. Модель данных должна быть пассивной. Разумеется, это не означает что данные не могут автоматом проверять ограничения.
2. Данные должны быть отделены от бизнес-логики.
Re[3]: Обращение к бизнеслогике приложения из сущности.
От: Blazkowicz Россия  
Дата: 22.12.10 17:10
Оценка: 2 (2)
Здравствуйте, Sinix, Вы писали:

B>>бизнес-логика и бизнес-сущности это единое целое — модель предметной области.

S>Смотря что вы понимаете под предметной областью. Если предметная область вашего приложения — то да. Если предметная область заказчика — то, очевидно, нет.
Бред какой-то. Приложение строится на основме МОДЕЛИ предметной области. При чем здесь какой-то асбстрактный "заказчик"? Это есть сущность финансовых отношений, а не разработки систем.

S>Сваливание логики и данных в одну кучу приводит к прогибанию структуры данных под текущие требования. Поддерживать получившееся месиво — занятие крайне неблагодарное.

Месиво получается у тех кто бросается в крайности.

S>1. Модель данных должна быть пассивной. Разумеется, это не означает что данные не могут автоматом проверять ограничения.

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

S>2. Данные должны быть отделены от бизнес-логики.

Данные не могут быть от неё отделены по ряду причин. Они без неё никому не нужны.
Re[4]: Обращение к бизнеслогике приложения из сущности.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 22.12.10 19:44
Оценка:
Здравствуйте, 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: Обращение к бизнеслогике приложения из сущности.
От: Achilles  
Дата: 22.12.10 21:07
Оценка:
Здравствуйте, testarch, Вы писали:

T>Подскажите насколько правильно/не правильно обращаться бизнеслогике приложения из сущности.


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

в другом приложении прогресс бар вызывал в классе, который напрямую с файловой системой общался

в целом ответ на ваш вопрос
можно, но крайне осторожно, тщательно комментируя все такие места

такого очень грязного кода в реальном приложении не избежать, но надо все контролировать, чтобы он был не более 1%-5% от всего кода приложения
общий объем грязного и грязноватого кода должен быть не более 15%
вводите для себя день (или 3 дня) рефакторинга — один раз в месяц
иначе система быстро рухнет и утонет в фекалиях
Re[2]: Обращение к бизнеслогике приложения из сущности.
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 22.12.10 22:19
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

B>Поищите по форуму про Rich Domain Model и Anemic Domain Model.

Интересно, может с той поры (тема-то давно обсуждалась) соотношение сторонников богатой или вялой модели изменилось.
Но в общем согласен, что обе модели имеют право на жизнь.
Re[4]: Обращение к бизнеслогике приложения из сущности.
От: Sinix  
Дата: 23.12.10 01:51
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

B>Бред какой-то. Приложение строится на основме МОДЕЛИ предметной области. При чем здесь какой-то асбстрактный "заказчик"? Это есть сущность финансовых отношений, а не разработки систем.


Ок. Попробуем ещё раз. Вы под предметной областью понимаете сам автоматизируемый бизнес, или предметную область бизнеса? Если второе, как можно догадаться исходя из "Это есть сущность финансовых отношений" — зачем валить в одну чучу особенности предметной области бизнеса (очевидно, эти особенности от заказчика не зависят) и особенности бизнес-логики (которые определяются набором текущих требований, которые, в свою очередь, покрывают только часть бизнеса заказчика)?

Самое смешное, что с вами несогласны и я, и ув. gandjustas, придерживающийся противоположной точки зрения на разработку.

S>>1. Модель данных должна быть пассивной. Разумеется, это не означает что данные не могут автоматом проверять ограничения.

B>Существуют разные подходы и в разных ситуациях они имееют право на жизнь. Выносить логику полностью построеную исключительно на свойсвах объекта за пределы этого объекта безсмысленно.

Это _сейчас_ ваш код оперирует данными только одного объекта. Появится новое требование — и всё изменится. Вы же не собираетесь ограничивать требования по принципу "вот это мы делать не будем — нам неудобно"?

S>>2. Данные должны быть отделены от бизнес-логики.

B>Данные не могут быть от неё отделены по ряду причин. Они без неё никому не нужны.
Мечты-мечты — данные куда важнее любой системы. Последнюю всегда можно заменить (если, конечно, внутри не ад, содом и гоморра, и этот кошмар не просочился в модель данных).
Re[5]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.12.10 14:48
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Есть класс A, который содержит некоторые данные описывающие предметную область, и метод B, реализующий некоторую функцию.

G>Функция в свою очередь обращается к другим данным (когда не обращается — нам неинтересно). То есть в A должна быть ссылка на DAL, tesability идет лесом и получается каша.

Это сферический коник
Re[5]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.12.10 15:23
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Ок. Попробуем ещё раз. Вы под предметной областью понимаете сам автоматизируемый бизнес, или предметную область бизнеса? Если второе, как можно догадаться исходя из "Это есть сущность финансовых отношений" — зачем валить в одну чучу особенности предметной области бизнеса (очевидно, эти особенности от заказчика не зависят) и особенности бизнес-логики (которые определяются набором текущих требований, которые, в свою очередь, покрывают только часть бизнеса заказчика)?


Предметная область есть у задачи Если посмотреть отсюда, то видно, что твое разделение сильно надуманое. Граница есть, но она нечеткая.

Часть функционала может измениться. Часть функционала — сильно вряд ли. Часть функционала имеет много зависимостей, часть функционала имеет мало зависимостей.

Вот эта разница и дает основания помещать методы в сущности или в сервисы или еще куда.

Хочешь понять эту разницу — надо разбираться с конкретной предметной областью. На примерах вроде "у класса A есть метод B" можно заехать куда угодно.
Re[6]: Обращение к бизнеслогике приложения из сущности.
От: Sinix  
Дата: 23.12.10 15:58
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Предметная область есть у задачи Если посмотреть отсюда, то видно, что твое разделение сильно надуманое. Граница есть, но она нечеткая.


И вам тоже здрваствуйте. Мы с вами буквально неделю назад обсуждали эту тему в три круга. Сегодня вы начинаете с того же — игнорируете мои доводы и даёте свои определения, без какого-либо доводов с вашей стороны. Пардон, но спорить впустую я не буду. ?
Re[7]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.12.10 16:17
Оценка:
Здравствуйте, Sinix, Вы писали:

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


I>>Предметная область есть у задачи Если посмотреть отсюда, то видно, что твое разделение сильно надуманое. Граница есть, но она нечеткая.


S>И вам тоже здрваствуйте. Мы с вами буквально неделю назад обсуждали эту тему в три круга. Сегодня вы начинаете с того же — игнорируете мои доводы и даёте свои определения, без какого-либо доводов с вашей стороны.


Я дал свои определения. А вот твоих так и не получил, т.е. вообще
Re[8]: Обращение к бизнеслогике приложения из сущности.
От: Sinix  
Дата: 23.12.10 16:27
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Я дал свои определения. А вот твоих так и не получил, т.е. вообще

Если вот это:
http://rsdn.ru/forum/design/4074960.aspx
Автор: Sinix
Дата: 11.12.10

http://rsdn.ru/forum/design/4075504.aspx
Автор: Sinix
Дата: 12.12.10

http://rsdn.ru/forum/design/4075603.aspx
Автор: Sinix
Дата: 12.12.10

я писал для вас зря — тем более нет никакого смысла продолжать.
Re[9]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.12.10 17:29
Оценка:
Здравствуйте, Sinix, Вы писали:

I>>Я дал свои определения. А вот твоих так и не получил, т.е. вообще

S>Если вот это:
S>http://rsdn.ru/forum/design/4074960.aspx
Автор: Sinix
Дата: 11.12.10

S>http://rsdn.ru/forum/design/4075504.aspx
Автор: Sinix
Дата: 12.12.10

S>http://rsdn.ru/forum/design/4075603.aspx
Автор: Sinix
Дата: 12.12.10

S>я писал для вас зря — тем более нет никакого смысла продолжать.

А я помнится написал тебе, что той разницы, которую ты хочешь видеть, просто нет

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

Между тем я более чем явно сделал это за тебя.

Все достаточно просто. Еет тех двух подходов к моделированию которые ты хочешь видеть. Твой подход N1 относится где к бизнес логистике, второй- ко всем остальным областям
Re[6]: Обращение к бизнеслогике приложения из сущности.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.12.10 18:34
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Хочешь понять эту разницу — надо разбираться с конкретной предметной областью. На примерах вроде "у класса A есть метод B" можно заехать куда угодно.


Подставь любую предметную область в указанный мной абстрактный пример и ты получишь одни и те же проблемы.

Кроме предметной области в любом её понимании есть вполне технические проблемы и принципы Data != Objects, SRP, принцип расслоения итп.
Re[7]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.12.10 19:53
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Хочешь понять эту разницу — надо разбираться с конкретной предметной областью. На примерах вроде "у класса A есть метод B" можно заехать куда угодно.


G>Подставь любую предметную область в указанный мной абстрактный пример и ты получишь одни и те же проблемы.


В том то и дело, что не получается, ибо пример у тебя слишком общий а хоть как то конкретизировать ты не можешь
Re[8]: Обращение к бизнеслогике приложения из сущности.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.12.10 20:00
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


I>>>Хочешь понять эту разницу — надо разбираться с конкретной предметной областью. На примерах вроде "у класса A есть метод B" можно заехать куда угодно.


G>>Подставь любую предметную область в указанный мной абстрактный пример и ты получишь одни и те же проблемы.


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


Еще раз: подставь любые сущности. Условие: Метод сущности X должен обращаться к связанной сущности Y, а еще лучше к коллекции Y.
Ты получишь абсолютно одинаковые проблемы, независимо от X и Y.
Re[9]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.12.10 20:02
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Еще раз: подставь любые сущности. Условие: Метод сущности X должен обращаться к связанной сущности Y, а еще лучше к коллекции Y.

G>Ты получишь абсолютно одинаковые проблемы, независимо от X и Y.

Чушь. Я вот как ни кручу, у меня не получается ссылки на dal как ты расписывал
Re[10]: Обращение к бизнеслогике приложения из сущности.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.12.10 20:08
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


G>>Еще раз: подставь любые сущности. Условие: Метод сущности X должен обращаться к связанной сущности Y, а еще лучше к коллекции Y.

G>>Ты получишь абсолютно одинаковые проблемы, независимо от X и Y.

I>Чушь. Я вот как ни кручу, у меня не получается ссылки на dal как ты расписывал


Show Me The Code. Я тебе покажу ссылку.
Re[11]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.12.10 20:11
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Чушь. Я вот как ни кручу, у меня не получается ссылки на dal как ты расписывал


G>Show Me The Code. Я тебе покажу ссылку.


Обычная модель графа — граф, узлы, ребра.
Re[12]: Обращение к бизнеслогике приложения из сущности.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.12.10 20:14
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


I>>>Чушь. Я вот как ни кручу, у меня не получается ссылки на dal как ты расписывал


G>>Show Me The Code. Я тебе покажу ссылку.


I>Обычная модель графа — граф, узлы, ребра.


Меня как всегда интересуют методы, а тебя "предметная область".

Так покажи каким сущностям предметной области соответствует твой граф, и скажи что за метод в любой сущности использует связанные.
Re[13]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.12.10 20:26
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Обычная модель графа — граф, узлы, ребра.


G>Меня как всегда интересуют методы, а тебя "предметная область".


G>Так покажи каким сущностям предметной области соответствует твой граф, и скажи что за метод в любой сущности использует связанные.


граф — сеть. узел — узел. ребро — линия связи.

Твоя формула "Есть класс A, который содержит некоторые данные описывающие предметную область, и метод B, реализующий некоторую функцию.
Функция в свою очередь обращается к другим данным (когда не обращается — нам неинтересно). То есть в A должна быть ссылка на DAL, tesability идет лесом и получается каша.
"

А = граф. Б — метод графа, например IsConnected, возвращает связный ли граф. Другие данные — вершины и ребра.

Итого — никаких ссылок на DAL не нужна.
Re[14]: Обращение к бизнеслогике приложения из сущности.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.12.10 20:37
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


I>>>Обычная модель графа — граф, узлы, ребра.


G>>Меня как всегда интересуют методы, а тебя "предметная область".


G>>Так покажи каким сущностям предметной области соответствует твой граф, и скажи что за метод в любой сущности использует связанные.


I>граф — сеть. узел — узел. ребро — линия связи.


I>Твоя формула "Есть класс A, который содержит некоторые данные описывающие предметную область, и метод B, реализующий некоторую функцию.

I>Функция в свою очередь обращается к другим данным (когда не обращается — нам неинтересно). То есть в A должна быть ссылка на DAL, tesability идет лесом и получается каша.
I>"

I>А = граф. Б — метод графа, например IsConnected, возвращает связный ли граф. Другие данные — вершины и ребра.


I>Итого — никаких ссылок на DAL не нужна.


Ты грузишь весь граф из хранилища в память?

Ну для начала. Думаю у графа есть значительно больше методов, чем IsConnected. Например возьмем простые и насущные: отображение
1)Список всех узлов.
2)Список всех линий.

Как они в такой модели решаться будут?

Ну покажи код, я прям потыкаю.
Re[3]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.12.10 00:00
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Сваливание логики и данных в одну кучу приводит к прогибанию структуры данных под текущие требования. Поддерживать получившееся месиво — занятие крайне неблагодарное.


Нет никакого сваливания в кучу

S>2. Данные должны быть отделены от бизнес-логики.


Это и ежу понятно. Речь о том, что Domain model это модель данных + бизнес-логика.
Re[15]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.12.10 00:06
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Итого — никаких ссылок на DAL не нужна.


G>Ты грузишь весь граф из хранилища в память?


Могу грузить, могу не грузить. В модели, сервисах нет никаких ссылок на DAL.

G>Ну для начала. Думаю у графа есть значительно больше методов, чем IsConnected. Например возьмем простые и насущные: отображение

G>1)Список всех узлов.
G>2)Список всех линий.

G>Как они в такой модели решаться будут?


Очень просто, путём итерации по коллекции.

G>Ну покажи код, я прям потыкаю.


Ты отказался не то что код показать, а даже мало мальски пояснить свою идею.

Все что я сейчас делаю — заставляю тебя пояснять твою же идею
Re[16]: Обращение к бизнеслогике приложения из сущности.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 24.12.10 08:13
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

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


I>>>Итого — никаких ссылок на DAL не нужна.


G>>Ты грузишь весь граф из хранилища в память?

I>Могу грузить, могу не грузить. В модели, сервисах нет никаких ссылок на DAL.
Покажи уже код.

G>>Ну для начала. Думаю у графа есть значительно больше методов, чем IsConnected. Например возьмем простые и насущные: отображение

G>>1)Список всех узлов.
G>>2)Список всех линий.
G>>Как они в такой модели решаться будут?
Запросом, Linq с проекцией.

I>Очень просто, путём итерации по коллекции.

А откуда коллекция берется?

G>>Ну покажи код, я прям потыкаю.

I>Ты отказался не то что код показать, а даже мало мальски пояснить свою идею.
I>Все что я сейчас делаю — заставляю тебя пояснять твою же идею
Да ты теперь увиливаешь. У тебя вообще нигде ссылок на dal нету, данные из воздуха появляются.

Вот давай возмем 3 юзкейса:
1)Проверка свзяности графа
2)Получение списка узлов
3)Получение списка ребер

И покажи код, который эффективно, с точки зрения трудозатрат и скорости работы, релизует эти юзкейсы.

Вот мой вариант:

public class GraphService
{
    IRepository<Vertex> verticesRepo;
    IRepository<Edge> edgesRepo;

    public GraphService(IRepository<Vertex> verticesRepo,
                        IRepository<Edge> edgesRepo)
    {
        this.verticesRepo = verticesRepo;
        this.edgesRepo = edgesRepo;
    }
 
    public bool IsGraphConnected(int graphId)
    {
        var q = from v in verticesRepo.Items()
                where v.GraphId == graphId
                select v;
        return IsConnected(AdjancedNodes(q)); 
    }

    public IQueryable<Vertex> ListVertivcies()
    {
        return verticesRepo.Items();
    }

    public IQueryable<Edge> ListVertivcies()
    {
        return edgesRepo.Items();
    }

    private ILookup<int,int> AdjancedNodes(IQueryable<Vertex> q)
    {
        return (from v in q
                from e in v.Edges
                select new {Left = v.Id, Right = e.ToId};
               .ToLookup(p => p.Left, p => p.Right);
    }

    private bool IsConnected(ILookup<int,int> adjancedNodes)
    {
        //skipped
    }
}


Модель данных:
public class Graph
{
    public int Id { get; set; }
    public ICollection<Vertex> Verticies { get; set; }
    //...
}

public class Vertex
{
    public int Id { get; set; }
    public int GraphId { get; set; }
    public Graph Graph { get; set; }

    public ICollection<Edge> Edges { get; set; }
    private ICollection<Edge> Edges1 { get; set; } //Для маппинга ассоциаций
    //...
}

public class Edge
{
    public int Id { get; set; }
    public int FromId { get; set; }
    public int ToId { get; set; }

    public Vertex From { get; set; }
    public Vertex To { get; set; }
    //...
}


Ты утверждаешь что можешь внести IsGraphConnected внутрь метода Graph без уменьшения эффективности программы и увеличения писанины.
Покажи как это сделать.
Re: Обращение к бизнеслогике приложения из сущности.
От: Аноним  
Дата: 24.12.10 11:53
Оценка:
Здравствуйте, testarch, Вы писали:

T>Подскажите насколько правильно/не правильно обращаться бизнеслогике приложения из сущности.


Имхо неправильно, т.к. сущности ничего не должны знать о бизнес логике, т.к. поведение все же должно быть локализовано в слое бизнес логики. С другой стороны часто нужен механизм реагирования на изменения состояния сущностей (скорее всего не всех, а каких-то конкретных). Этот механизм легко реализуется используя шаблон обратной зависимости.
Re[17]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.12.10 12:06
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Ты грузишь весь граф из хранилища в память?

I>>Могу грузить, могу не грузить. В модели, сервисах нет никаких ссылок на DAL.
G>Покажи уже код.

40мб ?

I>>Очень просто, путём итерации по коллекции.

G>А откуда коллекция берется?

Создается в рантайме некоторым алгоритмом. Этим алгоритмом может быть как известный тебе cost based mesh design , так и import, load и тд.

I>>Все что я сейчас делаю — заставляю тебя пояснять твою же идею

G>Да ты теперь увиливаешь. У тебя вообще нигде ссылок на dal нету, данные из воздуха появляются.

Почему же нигде. Модель и BL про DAL ничего не знают, но это ж не значит что нигде не этот DAL нет ссылок

G>Вот давай возмем 3 юзкейса:

G>1)Проверка свзяности графа
G>2)Получение списка узлов
G>3)Получение списка ребер

G>И покажи код, который эффективно, с точки зрения трудозатрат и скорости работы, релизует эти юзкейсы.


Эффективно для абстрактного приложения или для конкретного ?

G>Вот мой вариант:


G>
G>public class GraphService
G>{
G>    private bool IsConnected(ILookup<int,int> adjancedNodes)
G>    {
G>        //skipped
G>    }
G>}
G>


Ты показал вcе что угодно, кроме IsConnected. Где проверка достижимости узлов ?

G>Ты утверждаешь что можешь внести IsGraphConnected внутрь метода Graph без уменьшения эффективности программы и увеличения писанины.

G>Покажи как это сделать.

Для начала давай определимся, пример для абстрактного приложения или для конкретного ?

Абстрактный случай я оставлю тебе, ты по ним большой специалист.

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

Если я скажу, что IsConnected используется как для валидации внутри модели(модель реактивная и умеет себя валидировать) так и для некоторых операций над моделью, ты сильно удивишься ?
Re[2]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.12.10 12:47
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Имхо неправильно, т.к. сущности ничего не должны знать о бизнес логике, т.к. поведение все же должно быть локализовано в слое бизнес логики. С другой стороны часто нужен механизм реагирования на изменения состояния сущностей (скорее всего не всех, а каких-то конкретных). Этот механизм легко реализуется используя шаблон обратной зависимости.


Бизнес-логика понятие сильно растяжимое
Re[18]: Обращение к бизнеслогике приложения из сущности.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 24.12.10 13:01
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


G>>>>Ты грузишь весь граф из хранилища в память?

I>>>Могу грузить, могу не грузить. В модели, сервисах нет никаких ссылок на DAL.
G>>Покажи уже код.
I>40мб ?
Не увиливай, я тебе пример дал на одну страницу, ты тоже можешь показать пример аналогичного размера.


I>>>Очень просто, путём итерации по коллекции.

G>>А откуда коллекция берется?
I>Создается в рантайме некоторым алгоритмом. Этим алгоритмом может быть как известный тебе cost based mesh design , так и import, load и тд.
Алгоритм откуда данные берет? Тоже из воздуха?

I>>>Все что я сейчас делаю — заставляю тебя пояснять твою же идею

G>>Да ты теперь увиливаешь. У тебя вообще нигде ссылок на dal нету, данные из воздуха появляются.
I>Почему же нигде. Модель и BL про DAL ничего не знают, но это ж не значит что нигде не этот DAL нет ссылок
Ты опять увиливаешь.

G>>Вот давай возмем 3 юзкейса:

G>>1)Проверка свзяности графа
G>>2)Получение списка узлов
G>>3)Получение списка ребер

G>>И покажи код, который эффективно, с точки зрения трудозатрат и скорости работы, релизует эти юзкейсы.

I>Эффективно для абстрактного приложения или для конкретного ?
Да неважно, самая затратная операция у тебя всегда будет одна при таких юзкейсах. Это доставание из базы.

G>>Вот мой вариант:


G>>
G>>public class GraphService
G>>{
G>>    private bool IsConnected(ILookup<int,int> adjancedNodes)
G>>    {
G>>        //skipped
G>>    }
G>>}
G>>


I>Ты показал вcе что угодно, кроме IsConnected. Где проверка достижимости узлов ?

Да простым breadth-first его сделать, это к вопросу архитектуры никак не относится.

G>>Ты утверждаешь что можешь внести IsGraphConnected внутрь метода Graph без уменьшения эффективности программы и увеличения писанины.

G>>Покажи как это сделать.
I>Для начала давай определимся, пример для абстрактного приложения или для конкретного ?
См выше.

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

Это сейчас меня не интересует. Меня интересует как писать код в данном случае.
Ты показать не можешь, пытаешься увиливать. Продолжай в том же духе и с тобой вообще никто общаться не будет.

I>Если я скажу, что IsConnected используется как для валидации внутри модели(модель реактивная и умеет себя валидировать) так и для некоторых операций над моделью, ты сильно удивишься ?

Абсолютно без разницы. См выше.
Re[3]: Обращение к бизнеслогике приложения из сущности.
От: Аноним  
Дата: 24.12.10 13:38
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Аноним, Вы писали:


А>>Имхо неправильно, т.к. сущности ничего не должны знать о бизнес логике, т.к. поведение все же должно быть локализовано в слое бизнес логики. С другой стороны часто нужен механизм реагирования на изменения состояния сущностей (скорее всего не всех, а каких-то конкретных). Этот механизм легко реализуется используя шаблон обратной зависимости.


I>Бизнес-логика понятие сильно растяжимое


Конечно, но системы надо структурировать единообразно.
Re[19]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.12.10 14:10
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Покажи уже код.

I>>40мб ?
G>Не увиливай, я тебе пример дал на одну страницу, ты тоже можешь показать пример аналогичного размера.

Ты уже показал необходимый минимум с той разницей что мне не нужен Service в конкретном случае.

I>>Создается в рантайме некоторым алгоритмом. Этим алгоритмом может быть как известный тебе cost based mesh design , так и import, load и тд.

G>Алгоритм откуда данные берет? Тоже из воздуха?

Алгоритм берет данные из своих параметров А параметры ему передает например cкрипт или код примерно такого вида:

var algEngine = container.Resolve<IAlgorithmManager>();
var loader = container.Resolve<ILoader>(connection); 

var newModel = algEngine.Apply(loader, oldModel);


I>>Почему же нигде. Модель и BL про DAL ничего не знают, но это ж не значит что нигде не этот DAL нет ссылок

G>Ты опять увиливаешь.

Тебе вероятно непонятно как можно жить без ссылок на DAL внутри модели и BL

G>>>И покажи код, который эффективно, с точки зрения трудозатрат и скорости работы, релизует эти юзкейсы.

I>>Эффективно для абстрактного приложения или для конкретного ?
G>Да неважно, самая затратная операция у тебя всегда будет одна при таких юзкейсах. Это доставание из базы.

Конечно. При этом она не имеет никакого отношения к бизнес-задаче. Поэтому она вынесена во внешний функционал, т.е. в инфраструктура.

Вот в этой инфраструктуре и будут ссылки на DAL.

I>>Ты показал вcе что угодно, кроме IsConnected. Где проверка достижимости узлов ?

G>Да простым breadth-first его сделать, это к вопросу архитектуры никак не относится.

Так и пиши — BFS, и не надо лепить порожние Linq-выражения.

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

G>Это сейчас меня не интересует. Меня интересует как писать код в данном случае.

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

I>>Если я скажу, что IsConnected используется как для валидации внутри модели(модель реактивная и умеет себя валидировать) так и для некоторых операций над моделью, ты сильно удивишься ?

G>Абсолютно без разницы. См выше.

Это так кажется, что без разницы. В твоем случае внезапно может оказаться что надо в модель данных вводить депенденс от BL или вообще все методы выбрасывать в BL.

Имеем следующее — метод IsConnected

1 зависит исключительн от внутренностей Graph 2 зависит исключительно от сущностей которые не существуют вне Graph, т.е. graph управляет временем жизни этих объхектов

Следовательно, это равносильно тому, что IsConnected зависит исключительно от Graph.

Итого у класса Graph будет метод IsConnected который будет выполнять BFS над коллекциями узлов и ребер.

Что бы поднять IsConnected на уровень выше, в BL, нужно иметь существенные основания.

При том минимуме что я показал, в этом нет необходимости.

Могу показать, какие будут изменение при введении новых требований, если хочешь.
Re[4]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.12.10 14:12
Оценка:
Здравствуйте, Аноним, Вы писали:

А>>>Имхо неправильно, т.к. сущности ничего не должны знать о бизнес логике, т.к. поведение все же должно быть локализовано в слое бизнес логики. С другой стороны часто нужен механизм реагирования на изменения состояния сущностей (скорее всего не всех, а каких-то конкретных). Этот механизм легко реализуется используя шаблон обратной зависимости.


I>>Бизнес-логика понятие сильно растяжимое


А>Конечно, но системы надо структурировать единообразно.


Единообразно это касается подхода или же дизайна ?

Если подхода — "выявить важнейшие требования и на этом основании предложить конкретную структуру", то я согласен.

А если единообразно это "у разных моделей должна быть одинаковая структура" то это к доктору.

Вот gangjustas все хочет убедить меня, что модель данных или BL просто обязаны иметь ссылку на DAL
Re[5]: Обращение к бизнеслогике приложения из сущности.
От: Аноним  
Дата: 24.12.10 14:29
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Единообразно это касается подхода или же дизайна ?


И того и другого, но конечно по мере сил

I>А если единообразно это "у разных моделей должна быть одинаковая структура" то это к доктору.


Я бы сказал — узнаваемая и привычная структура

I>Вот gangjustas все хочет убедить меня, что модель данных или BL просто обязаны иметь ссылку на DAL


Думаю вы о разных вещах говорите, в роли DAL например WCF может быть использован...
Re[6]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.12.10 15:14
Оценка:
Здравствуйте, Аноним, Вы писали:

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


I>>Единообразно это касается подхода или же дизайна ?


А>И того и другого, но конечно по мере сил


I>>А если единообразно это "у разных моделей должна быть одинаковая структура" то это к доктору.


А> Я бы сказал — узнаваемая и привычная структура


I>>Вот gangjustas все хочет убедить меня, что модель данных или BL просто обязаны иметь ссылку на DAL


А>Думаю вы о разных вещах говорите, в роли DAL например WCF может быть использован...


Конечно может. Но это не значит что в модели и BL будет ссылка на этот DAL
Re[20]: Обращение к бизнеслогике приложения из сущности.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 24.12.10 16:45
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Создается в рантайме некоторым алгоритмом. Этим алгоритмом может быть как известный тебе cost based mesh design , так и import, load и тд.

G>>Алгоритм откуда данные берет? Тоже из воздуха?

I>Алгоритм берет данные из своих параметров А параметры ему передает например cкрипт или код примерно такого вида:


I>
I>var algEngine = container.Resolve<IAlgorithmManager>();
I>var loader = container.Resolve<ILoader>(connection); 

I>var newModel = algEngine.Apply(loader, oldModel);
I>


Вот прекрасно, а скрипт этот где находится?
и приведи контракты IAlgorithmManager и ILoader.

I>>>Почему же нигде. Модель и BL про DAL ничего не знают, но это ж не значит что нигде не этот DAL нет ссылок

G>>Ты опять увиливаешь.
I>Тебе вероятно непонятно как можно жить без ссылок на DAL внутри модели и BL
Мне-то как раз понятно. А вот в Rich так не получится.

G>>>>И покажи код, который эффективно, с точки зрения трудозатрат и скорости работы, релизует эти юзкейсы.

I>>>Эффективно для абстрактного приложения или для конкретного ?
G>>Да неважно, самая затратная операция у тебя всегда будет одна при таких юзкейсах. Это доставание из базы.
I>Конечно. При этом она не имеет никакого отношения к бизнес-задаче. Поэтому она вынесена во внешний функционал, т.е. в инфраструктура.
Он того что ты назвал вещь по-другому код у тебя правильнее не станет.

I>Так и пиши — BFS, и не надо лепить порожние Linq-выражения.

Мы тут о работе с persisted данными говорим. Остальное не интересует и к архитектуре имеет посредственное отношение.

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

G>>Это сейчас меня не интересует. Меня интересует как писать код в данном случае.
I>Вообще то должно интересовать, если ты хочешь поместить этот метод в правильное место. А особенно важно, если ты хочешь добиться того, что бы и другие девелоперы помещали методы в правильных местах, а не где попало.
Ты вроде привел код с service locator, а говоришь какую-то чушь. Важно чтобы девелоперы реализовали правильный интрефейс и положили классы в контейнер. Второе вообще говоря может делаться автоматически.

I>>>Если я скажу, что IsConnected используется как для валидации внутри модели(модель реактивная и умеет себя валидировать) так и для некоторых операций над моделью, ты сильно удивишься ?

G>>Абсолютно без разницы. См выше.

I>Это так кажется, что без разницы. В твоем случае внезапно может оказаться что надо в модель данных вводить депенденс от BL или вообще все методы выбрасывать в BL.

Ни разу такого не видел и даже причин не могу придумать от чего такая зависимость может получиться.

I>Имеем следующее — метод IsConnected

I>1 зависит исключительн от внутренностей Graph 2 зависит исключительно от сущностей которые не существуют вне Graph, т.е. graph управляет временем жизни этих объхектов
I>Следовательно, это равносильно тому, что IsConnected зависит исключительно от Graph.
I>Итого у класса Graph будет метод IsConnected который будет выполнять BFS над коллекциями узлов и ребер.
I>Что бы поднять IsConnected на уровень выше, в BL, нужно иметь существенные основания.
I>При том минимуме что я показал, в этом нет необходимости.
I>Могу показать, какие будут изменение при введении новых требований, если хочешь.
Ну ты считаешь изначально что все методы должны быть в объектах, а я считаю наоборот.

Вот я привел код, попробуй поместить IsConnected класс Graph, если уверен что там ему и место, но чтобы не поломались другие юзкейсы.
Re[21]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.12.10 10:51
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>
I>>var algEngine = container.Resolve<IAlgorithmManager>();
I>>var loader = container.Resolve<ILoader>(connection); 

I>>var newModel = algEngine.Apply(loader, oldModel);
I>>


G>Вот прекрасно, а скрипт этот где находится?


На диске и редактируется пользователем

G>и приведи контракты IAlgorithmManager и ILoader.


IModel Apply(IAlgorithm alg, IModel model);

void Run(Context ctx);

I>>Тебе вероятно непонятно как можно жить без ссылок на DAL внутри модели и BL

G>Мне-то как раз понятно. А вот в Rich так не получится.

Это так кажется.

I>>Конечно. При этом она не имеет никакого отношения к бизнес-задаче. Поэтому она вынесена во внешний функционал, т.е. в инфраструктура.

G>Он того что ты назвал вещь по-другому код у тебя правильнее не станет.

Опять пурга какая то. Объясняю по русски — в модели и BL нет ссылок на DAL.

I>>Так и пиши — BFS, и не надо лепить порожние Linq-выражения.

G>Мы тут о работе с persisted данными говорим. Остальное не интересует и к архитектуре имеет посредственное отношение.

Наоборот, имеет непосредтсвенное отношение и я уже объяснил почему.

G>Ты вроде привел код с service locator, а говоришь какую-то чушь. Важно чтобы девелоперы реализовали правильный интрефейс и положили классы в контейнер. Второе вообще говоря может делаться автоматически.


Придется решить ту же задачу — надо знать где искать какой метод, вводить новый интерфейс или не вводить.

I>>Это так кажется, что без разницы. В твоем случае внезапно может оказаться что надо в модель данных вводить депенденс от BL или вообще все методы выбрасывать в BL.

G>Ни разу такого не видел и даже причин не могу придумать от чего такая зависимость может получиться.

А было написано русским по зелёному

I>>При том минимуме что я показал, в этом нет необходимости.

I>>Могу показать, какие будут изменение при введении новых требований, если хочешь.
G>Ну ты считаешь изначально что все методы должны быть в объектах, а я считаю наоборот.

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

Судя по всему ты или не способен прочесть или просто валяешь дурака.

G>Вот я привел код, попробуй поместить IsConnected класс Graph, если уверен что там ему и место, но чтобы не поломались другие юзкейсы.


Какие "другие юзкейсы" ? На чем основана твоя уверенность, на книжках модных ?

Ты даже объяснить не можешь, чем руководствоваться для размещения метода в нужном месте.
Re[22]: Обращение к бизнеслогике приложения из сущности.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.12.10 12:33
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


I>>>
I>>>var algEngine = container.Resolve<IAlgorithmManager>();
I>>>var loader = container.Resolve<ILoader>(connection); 

I>>>var newModel = algEngine.Apply(loader, oldModel);
I>>>


G>>Вот прекрасно, а скрипт этот где находится?


I>На диске и редактируется пользователем

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


G>>и приведи контракты IAlgorithmManager и ILoader.

I>IModel Apply(IAlgorithm alg, IModel model);
I>void Run(Context ctx);
Это к чему относится?

I>>>Тебе вероятно непонятно как можно жить без ссылок на DAL внутри модели и BL

G>>Мне-то как раз понятно. А вот в Rich так не получится.
I>Это так кажется.
Это так и есть

I>>>Конечно. При этом она не имеет никакого отношения к бизнес-задаче. Поэтому она вынесена во внешний функционал, т.е. в инфраструктура.

G>>Он того что ты назвал вещь по-другому код у тебя правильнее не станет.
I>Опять пурга какая то. Объясняю по русски — в модели и BL нет ссылок на DAL.
А ты не словами объясняй, а покажи на примере, я тебе привел пример для anemic, покажи как он же будет в rich.
А ты показал какие-то отдельные компоненты, а сама архитектура (взаимодействие компонент) отдано пользователю.

I>>>Так и пиши — BFS, и не надо лепить порожние Linq-выражения.

G>>Мы тут о работе с persisted данными говорим. Остальное не интересует и к архитектуре имеет посредственное отношение.
I>Наоборот, имеет непосредтсвенное отношение и я уже объяснил почему.
Не объяснил, ты пытался уйти от темы.


I>>>При том минимуме что я показал, в этом нет необходимости.

I>>>Могу показать, какие будут изменение при введении новых требований, если хочешь.
G>>Ну ты считаешь изначально что все методы должны быть в объектах, а я считаю наоборот.
I>Вообще то я привел свои рассуждения на счет того, почему конкретный метод должен оказаться именно у Graph.
Еще раз. Твои рассуждения опираются на то что ты считаешь что методы должны быть в классах с данными, есть и другая точка зрения.


G>>Вот я привел код, попробуй поместить IsConnected класс Graph, если уверен что там ему и место, но чтобы не поломались другие юзкейсы.

I>Какие "другие юзкейсы" ?
Не включай дурачка, я писал три юзкейса:

1)Список всех узлов.
2)Список всех линий.
3)Метод IsConnected.

И привел тебе еще пример кода, который показываем взаимодействие частей программы.

I>На чем основана твоя уверенность, на книжках модных ?

В книжках пишут про DDD и другие модные акронимы.

I>Ты даже объяснить не можешь, чем руководствоваться для размещения метода в нужном месте.

Ты не читаешь чтоли?
Я уже писал: функции могут группироваться по
1)Входным данным (это в точности методы класса)
2)Выходным данным
3)По решаемым задачам

Я предпочитаю группировать по 3), иногда по 1) и 2), причем все методы в отдельных "сервисах", те классах без состояния и identity.
Re[23]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.12.10 13:07
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>На диске и редактируется пользователем

G>На этом месте разговор можно закончить вообще говоря.
G>Архитектуры у программы нет, если взаимодействие компонент отдано пользователю.

Цитирую: "А параметры ему передает например cкрипт или код примерно такого вида: "

У тебя какие то проблемы со словом "например" ?

У тебя какие то проблемы с приведеным кодом ? Вроде всего три строчки было

Взаимодействие компонент может описываться скриптом. Но это не значит что пользователь обязан этим заниматься. Loader вполне может быть вызван из скрипта и пользователь может передать туда параметры.

G>>>и приведи контракты IAlgorithmManager и ILoader.

I>>IModel Apply(IAlgorithm alg, IModel model);
I>>void Run(Context ctx);
G>Это к чему относится?

Угадай с трех раз что называется. Первая строка — менеджер алгоритмов, вторая — алгоритм. ILoader — всего лишь специальное имя интерфейса.

I>>Опять пурга какая то. Объясняю по русски — в модели и BL нет ссылок на DAL.

G>А ты не словами объясняй, а покажи на примере, я тебе привел пример для anemic, покажи как он же будет в rich.

Честно говоря я не сильно понимаю, что такое rich а что такое anemic. Где ты хочешь увидеть ссылку на DAL ?

G>А ты показал какие-то отдельные компоненты, а сама архитектура (взаимодействие компонент) отдано пользователю.


Вообще то ты плохо читал.

G>>>Ну ты считаешь изначально что все методы должны быть в объектах, а я считаю наоборот.

I>>Вообще то я привел свои рассуждения на счет того, почему конкретный метод должен оказаться именно у Graph.
G>Еще раз. Твои рассуждения опираются на то что ты считаешь что методы должны быть в классах с данными, есть и другая точка зрения.

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

"Имеем следующее — метод IsConnected

1 зависит исключительн от внутренностей Graph 2 зависит исключительно от сущностей которые не существуют вне Graph, т.е. graph управляет временем жизни этих объхектов

Следовательно, это равносильно тому, что IsConnected зависит исключительно от Graph.

Итого у класса Graph будет метод IsConnected который будет выполнять BFS над коллекциями узлов и ребер."


I>>Какие "другие юзкейсы" ?

G>

G>1)Список всех узлов.
G>2)Список всех линий.
G>3)Метод IsConnected.


Из твоего кода выбросить GraphService и перенести метод IsConnected в Graph. Это что, так сложно ?

G>И привел тебе еще пример кода, который показываем взаимодействие частей программы.


Ты эти части сам же искусственно и ввел.

G>Я уже писал: функции могут группироваться по

G>1)Входным данным (это в точности методы класса)
G>2)Выходным данным
G>3)По решаемым задачам

Это общие слова.
Re[24]: Обращение к бизнеслогике приложения из сущности.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.12.10 13:52
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


I>>>На диске и редактируется пользователем

G>>На этом месте разговор можно закончить вообще говоря.
G>>Архитектуры у программы нет, если взаимодействие компонент отдано пользователю.

I>Цитирую: "А параметры ему передает например cкрипт или код примерно такого вида: "


I>У тебя какие то проблемы со словом "например" ?


I>У тебя какие то проблемы с приведеным кодом ? Вроде всего три строчки было


I>Взаимодействие компонент может описываться скриптом. Но это не значит что пользователь обязан этим заниматься. Loader вполне может быть вызван из скрипта и пользователь может передать туда параметры.


G>>>>и приведи контракты IAlgorithmManager и ILoader.

I>>>IModel Apply(IAlgorithm alg, IModel model);
I>>>void Run(Context ctx);
G>>Это к чему относится?

I>Угадай с трех раз что называется. Первая строка — менеджер алгоритмов, вторая — алгоритм. ILoader — всего лишь специальное имя интерфейса.

Точно?
Твой код

var algEngine = container.Resolve<IAlgorithmManager>();
var loader = container.Resolve<ILoader>(connection); 

var newModel = algEngine.Apply(loader, oldModel);


Мой внутренний компилятор подсказывает что из-за выделенного проверку типов не пройдет.

Ну тем не менее давай углубляться, как устроен Run и что есть IModel?

I>>>Опять пурга какая то. Объясняю по русски — в модели и BL нет ссылок на DAL.

G>>А ты не словами объясняй, а покажи на примере, я тебе привел пример для anemic, покажи как он же будет в rich.

I>Честно говоря я не сильно понимаю, что такое rich а что такое anemic.

Однако... почитай темы с более чем 200 постами в этом форуме.


G>>А ты показал какие-то отдельные компоненты, а сама архитектура (взаимодействие компонент) отдано пользователю.

I>Вообще то ты плохо читал.
Да ты че? ты привел 3 строчки кода непонятного происхождения и еще объявил что за них пользователь отвечает. Я вообще не пойму какой код ты пишешь, а ты вечно уходишь от темы.


I>"Имеем следующее — метод IsConnected

I>1 зависит исключительн от внутренностей Graph 2 зависит исключительно от сущностей которые не существуют вне Graph, т.е. graph управляет временем жизни этих объхектов
I>Следовательно, это равносильно тому, что IsConnected зависит исключительно от Graph. (1)
I>Итого у класса Graph будет метод IsConnected который будет выполнять BFS над коллекциями узлов и ребер." (2)
Если у тебя Graph — persisted сущность, то есть сохраняется в базе, то это уже неверно.

I>>>Какие "другие юзкейсы" ?

G>>

G>>1)Список всех узлов.
G>>2)Список всех линий.
G>>3)Метод IsConnected.


I>Из твоего кода выбросить GraphService и перенести метод IsConnected в Graph. Это что, так сложно ?

Данивопрос, покажи кож. Выполняться должны все 3 юзкейса.

G>>И привел тебе еще пример кода, который показываем взаимодействие частей программы.

I>Ты эти части сам же искусственно и ввел.
Какие именно?

G>>Я уже писал: функции могут группироваться по

G>>1)Входным данным (это в точности методы класса)
G>>2)Выходным данным
G>>3)По решаемым задачам
I>Это общие слова.
Если не понимаешь, то помочь я не могу.
Re[25]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.12.10 16:28
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Угадай с трех раз что называется. Первая строка — менеджер алгоритмов, вторая — алгоритм. ILoader — всего лишь специальное имя интерфейса.

G>Точно?
G>Твой код

G>
G>var algEngine = container.Resolve<IAlgorithmManager>();
G>var loader = container.Resolve<ILoader>(connection); 

G>var newModel = algEngine.Apply(loader, oldModel);
G>


G>Мой внутренний компилятор подсказывает что из-за выделенного проверку типов не пройдет.


Маркерный интерфейс тебя смутил ?
interface ILoader : IAlogrithm {}



G>Ну тем не менее давай углубляться, как устроен Run и что есть IModel?


Run это и есть твой алгоритм. Как напишешь его, так он и будет устроен IModel это интерфейс рутового объекта модели. Он нужен для того, что бы разделить инфраструкту и модель. Ты ж понимаешь, что тащить Graph в другое приложение нет никакого резона.

I>>Честно говоря я не сильно понимаю, что такое rich а что такое anemic.

G>Однако... почитай темы с более чем 200 постами в этом форуме.

Так читал неоднократно Сторонники анемик и рич дошли до того, что у анемистов появились методы в прямо в модели, а у рич нарисовался слой сервисов

I>>Вообще то ты плохо читал.

G>Да ты че? ты привел 3 строчки кода непонятного происхождения и еще объявил что за них пользователь отвечает. Я вообще не пойму какой код ты пишешь, а ты вечно уходишь от темы.

Ответ был даден предельно ясно — "например скрипт" или "код примерно такого вида...".

У тебя возникли какие то проблемы с этим ?

I>>Следовательно, это равносильно тому, что IsConnected зависит исключительно от Graph. (1)

I>>Итого у класса Graph будет метод IsConnected который будет выполнять BFS над коллекциями узлов и ребер." (2)
G>Если у тебя Graph — persisted сущность, то есть сохраняется в базе, то это уже неверно.

А что такое persisted сущность в твоем понимании ? Хочу уточнить, а то мне совсем неохота открывать очередной источник буззвордов, общих фраз и порожнего кода

I>>Из твоего кода выбросить GraphService и перенести метод IsConnected в Graph. Это что, так сложно ?

G>Данивопрос, покажи кож. Выполняться должны все 3 юзкейса.

Смотри внимательно:
public class Graph : Base
{
    public ICollection<Vertex> Verticies { get; set; }
    public ICollection<Edge> Edges { get; set; }
    /// 
    public bool IsConnected();
    //...
}

public class Vertex  : Base
{
    public ICollection<Edge> Edges { get; set; }
}

public class Edge : Base
{
    public Vertex A { get; set; }
    public Vertex Z { get; set; }
    //...
    public GetAnotherEnd(Vertex v);
}

public class Base
{
    public int Id {get;set;}
    public Base Parent{get;set;}
}

Хватит столько или еще чего добавить ?

G>>>И привел тебе еще пример кода, который показываем взаимодействие частей программы.

I>>Ты эти части сам же искусственно и ввел.
G>Какие именно?

я имею ввиду выделение GraphService.

G>>>Я уже писал: функции могут группироваться по

G>>>1)Входным данным (это в точности методы класса)
G>>>2)Выходным данным
G>>>3)По решаемым задачам
I>>Это общие слова.
G>Если не понимаешь, то помочь я не могу.

Чего я понимаю, что ты читаешь и что ты пишешь это ажно ТРИ большие разницы
Re[26]: Обращение к бизнеслогике приложения из сущности.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.12.10 20:13
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


I>>>Угадай с трех раз что называется. Первая строка — менеджер алгоритмов, вторая — алгоритм. ILoader — всего лишь специальное имя интерфейса.

G>>Точно?
G>>Твой код

G>>
G>>var algEngine = container.Resolve<IAlgorithmManager>();
G>>var loader = container.Resolve<ILoader>(connection); 

G>>var newModel = algEngine.Apply(loader, oldModel);
G>>


G>>Мой внутренний компилятор подсказывает что из-за выделенного проверку типов не пройдет.


I>Маркерный интерфейс тебя смутил ?
interface ILoader : IAlogrithm {}

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


G>>Ну тем не менее давай углубляться, как устроен Run и что есть IModel?


I>Run это и есть твой алгоритм. Как напишешь его, так он и будет устроен IModel это интерфейс рутового объекта модели. Он нужен для того, что бы разделить инфраструкту и модель. Ты ж понимаешь, что тащить Graph в другое приложение нет никакого резона.

Давай подробнее, какие методы в IModel, и как в коде появляется oldModel

I>>>Честно говоря я не сильно понимаю, что такое rich а что такое anemic.

G>>Однако... почитай темы с более чем 200 постами в этом форуме.

I>Так читал неоднократно Сторонники анемик и рич дошли до того, что у анемистов появились методы в прямо в модели, а у рич нарисовался слой сервисов

На выделенное приведешь ссылку?

I>>>Вообще то ты плохо читал.

G>>Да ты че? ты привел 3 строчки кода непонятного происхождения и еще объявил что за них пользователь отвечает. Я вообще не пойму какой код ты пишешь, а ты вечно уходишь от темы.

I>Ответ был даден предельно ясно — "например скрипт" или "код примерно такого вида...".

I>У тебя возникли какие то проблемы с этим ?
Ответ то ясен, а кода нет. Можно считать сознательным уходом от темы и прекратить разговор.

I>>>Следовательно, это равносильно тому, что IsConnected зависит исключительно от Graph. (1)

I>>>Итого у класса Graph будет метод IsConnected который будет выполнять BFS над коллекциями узлов и ребер." (2)
G>>Если у тебя Graph — persisted сущность, то есть сохраняется в базе, то это уже неверно.

I>А что такое persisted сущность в твоем понимании ? Хочу уточнить, а то мне совсем неохота открывать очередной источник буззвордов, общих фраз и порожнего кода

См выделенное выше. Ты походу вообще не читаешь.

I>>>Из твоего кода выбросить GraphService и перенести метод IsConnected в Graph. Это что, так сложно ?

G>>Данивопрос, покажи кож. Выполняться должны все 3 юзкейса.

I>Смотри внимательно:

I>
I>public class Graph : Base
I>{
I>    public ICollection<Vertex> Verticies { get; set; }
I>    public ICollection<Edge> Edges { get; set; }
I>    /// 
I>    public bool IsConnected();
I>    //...
I>}

I>public class Vertex  : Base
I>{
I>    public ICollection<Edge> Edges { get; set; }
I>}

I>public class Edge : Base
I>{
I>    public Vertex A { get; set; }
I>    public Vertex Z { get; set; }
I>    //...
I>    public GetAnotherEnd(Vertex v);
I>}

I>public class Base
I>{
I>    public int Id {get;set;}
I>    public Base Parent{get;set;}
I>}
I>

I>Хватит столько или еще чего добавить ?
Конечно добавить, методы поулчения списка вершин и дуг, причем не для одного графа, а всех.
А теперь самый интересный вопрос. Очевидно IsConnected обращается к Verticies и Edges, но если это не LL коллекции, то у тебя может падать IsConneted если не загружены связанные сущности. То есть ты не сможешь обеспечить независимость от DAL, то у тебя будет или LL — ссылка на DAL, или неявная связь с DAL, которая тебя явно грузить связанные сущности до вызова IsConnected.
Как будешь бороть?


G>>>>И привел тебе еще пример кода, который показываем взаимодействие частей программы.

I>>>Ты эти части сам же искусственно и ввел.
G>>Какие именно?
I>я имею ввиду выделение GraphService.
И че?

G>>>>Я уже писал: функции могут группироваться по

G>>>>1)Входным данным (это в точности методы класса)
G>>>>2)Выходным данным
G>>>>3)По решаемым задачам
I>>>Это общие слова.
G>>Если не понимаешь, то помочь я не могу.

I>Чего я понимаю, что ты читаешь и что ты пишешь это ажно ТРИ большие разницы

Ну так если ты не читаешь или не понимаешь что я пишу, то это не мои проблемы.
Re[27]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.12.10 21:39
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Маркерный интерфейс тебя смутил ?
interface ILoader : IAlogrithm {}

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

Очень удобно, решает многие вопросы конфигурации.

I>>Run это и есть твой алгоритм. Как напишешь его, так он и будет устроен IModel это интерфейс рутового объекта модели. Он нужен для того, что бы разделить инфраструкту и модель. Ты ж понимаешь, что тащить Graph в другое приложение нет никакого резона.

G>Давай подробнее, какие методы в IModel, и как в коде появляется oldModel

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

IModel
object Root {get;set}


I>>Так читал неоднократно Сторонники анемик и рич дошли до того, что у анемистов появились методы в прямо в модели, а у рич нарисовался слой сервисов

G>На выделенное приведешь ссылку?

Попроси, что бы прикрутили нормальный поиск к rsdn, найду.

I>>Ответ был даден предельно ясно — "например скрипт" или "код примерно такого вида...".

I>>У тебя возникли какие то проблемы с этим ?
G>Ответ то ясен, а кода нет. Можно считать сознательным уходом от темы и прекратить разговор.

Код вообще то был. Ты его не понял что ли ?

I>>А что такое persisted сущность в твоем понимании ? Хочу уточнить, а то мне совсем неохота открывать очередной источник буззвордов, общих фраз и порожнего кода

G>См выделенное выше. Ты походу вообще не читаешь.

Понятнее мне не стало, но если ты не хочешь пояснять — не надо.

G>Конечно добавить, методы поулчения списка вершин и дуг, причем не для одного графа, а всех.


Разуй глаза — все что надо есть.

Модель пишется под конкретное использование, а не под любое. Отсюда и разница в дизайне Потому не надо никаких дополнительных методов.

G>А теперь самый интересный вопрос. Очевидно IsConnected обращается к Verticies и Edges, но если это не LL коллекции, то у тебя может падать IsConneted если не загружены связанные сущности. То есть ты не сможешь обеспечить независимость от DAL, то у тебя будет или LL — ссылка на DAL, или неявная связь с DAL, которая тебя явно грузить связанные сущности до вызова IsConnected.

G>Как будешь бороть?

Сначала ты искал ссылку на DAL, щас вот уже ищешь неявную связь с DAL. Конечно же эта неявная связь есть и я даже говорил и не раз, где она — ни в модели, ни в BL, но в инфраструктуре и вызывающем коде

I>>Чего я понимаю, что ты читаешь и что ты пишешь это ажно ТРИ большие разницы

G>Ну так если ты не читаешь или не понимаешь что я пишу, то это не мои проблемы.

Наоборот, это ты ничего не читаешь, потому что каждый вопрос надо по три раза рассусоливать.
Re[28]: Обращение к бизнеслогике приложения из сущности.
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 27.12.10 08:09
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Разуй глаза — все что надо есть.

Покажи код.

I>Модель пишется под конкретное использование, а не под любое. Отсюда и разница в дизайне Потому не надо никаких дополнительных методов.

То есть модель таки зависит от функций, а не от "предметной области". Ты помницца пытался доказать обратное, или не ты?
Re[29]: Обращение к бизнеслогике приложения из сущности.
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.12.10 11:55
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Разуй глаза — все что надо есть.

G>Покажи код.

Не смешная шутка. Ты видел код и снова просишь его показать

I>>Модель пишется под конкретное использование, а не под любое. Отсюда и разница в дизайне Потому не надо никаких дополнительных методов.

G>То есть модель таки зависит от функций, а не от "предметной области".

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

>Ты помницца пытался доказать обратное, или не ты?


Похоже у тебя хронические проблемы с чтением.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.