Здравствуйте, meowth, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, meowth, Вы писали:
M>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Я говорил про модель на сервере. M>>>Тем не менее, при наличии SyncFramework, как вы предложили, объекты никуда гонять не надо, следовательно, rich model отлично подходит. Не понимаю, почему она — "сосет как пылесос" в таком случае. G>>"объекты никуда гонять не надо" — единственный критерий чтоли?
M>Нет, но вы на больше и не указывали в этом треде.
M>Эм, а почему вы отвечаете вопросом на вопрос? Я у вас уже 4м комментом пытаюсь спросить, почему rich model плоха в условиях, если есть Sync Framework, как вы предлагаете взять. А если не предлагаете, выяснив, что клиент 2хзвенный, то вопрос никуда не девается -- почему в 2хзвенке rich model плоха; предметно ответьте? Только не надо про SRP.
SRP это самое главное, практически на одном уровне важности с нормальзацией данных находится. Более того, можно доказать что нормализация — это и есть SRP на уровне данных.
Теперь к практике.
Rich плоха тем, что далеко не все можно выразит в rich, например произвольные выборки и опрации задействующие несколько объектов.
Кроме того не вижу преимуществ rich, чтобы стремиться её использовать.
Re[16]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, gandjustas, Вы писали:
G>SRP это самое главное, практически на одном уровне важности с нормальзацией данных находится. Более того, можно доказать что нормализация — это и G>есть SRP на уровне данных.
Я не вижу, чтобы rich model нарушала SRP. А если нарушает, покажите мне в цифрах, во что мне это выливается.
И странно, что вы в anemic model не остановились на использовании typed datasets -- а чо, pure data )
G>Теперь к практике. G>Rich плоха тем, что далеко не все можно выразит в rich, например произвольные выборки и опрации задействующие несколько объектов.
Во первых, произвольные операции выборки не нужны при манипуляции с domain model в пределах бизнес-процесса. Они становятся нужны только в UI и Reporting'e, где и так есть DTO, в которые можно загнать нужные поля объектов проекциями и срезами из query language, не подтягивая весь объект целиком.
G>операции задействующие несколько объектов
Вообще не понял о_О Как это -- в rich model нельзя оперировать несколькими объектами?
G>Кроме того не вижу преимуществ rich, чтобы стремиться её использовать.
*развер руками* ну увы =)
Re[17]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, meowth, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>SRP это самое главное, практически на одном уровне важности с нормальзацией данных находится. Более того, можно доказать что нормализация — это и G>>есть SRP на уровне данных. M>Я не вижу, чтобы rich model нарушала SRP.
Да это вроде всем известно: rich прибивает БЛ к объктам, хранящим данные.
Например если валидацию засунуть в внутрь объекта, то становится невозможно автоматически генерировать клиентские валидаторы для веб-интерфейса.
M>А если нарушает, покажите мне в цифрах, во что мне это выливается.
Эх, если бы в цифрах это можно было оценить уже холиваров бы не было.
M>И странно, что вы в anemic model не остановились на использовании typed datasets -- а чо, pure data )
те же проблемы. Произвольные выборки не поддерживаются. Да и текстовый SQL писать надо — неудобно. Кроме того датасеты очень громозкие.
Гораздо удобнее список "записей" (неизменяемых структур со структурной эквивалентностью), но ни язык не поддерживает, ни средств отображения для таких структур нету.
Может быть на базе следующего EF такое можно будет собрать. А сейчас с нуля создавать — дороговато будет.
G>>Теперь к практике. G>>Rich плоха тем, что далеко не все можно выразит в rich, например произвольные выборки и опрации задействующие несколько объектов. M>Во первых, произвольные операции выборки не нужны при манипуляции с domain model в пределах бизнес-процесса. Они становятся нужны только в UI и Reporting'e, где и так есть DTO, в которые можно загнать нужные поля объектов проекциями и срезами из query language, не подтягивая весь объект целиком.
G>>операции задействующие несколько объектов M>Вообще не понял о_О Как это -- в rich model нельзя оперировать несколькими объектами?
А куда методы оперирующие объектами A, B, C помещать?
В отдельные сервисы, а значит вся "красота", за которую бъются приверженцы rich, теряется.
Re[18]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, meowth, Вы писали: G>Да это вроде всем известно: rich прибивает БЛ к объктам, хранящим данные.
Rich model не занимается _хранением _данных. Она отвечает за их представление и поведение. Хранение и транспорт -- это anemic/DTO. Попробуйте посмотреть с этой точки зрения. Вы смотрите с точки зрения данные + операции. Представьте себе ООСУБД. Не обсуждая минусы, с вашей точки зрения, она вообще существовать -- не может: ее факт существования просто противоречит реальности true anemic.
M>>А если нарушает, покажите мне в цифрах, во что мне это выливается. G>Эх, если бы в цифрах это можно было оценить уже холиваров бы не было.
M>>И странно, что вы в anemic model не остановились на использовании typed datasets -- а чо, pure data ) G>те же проблемы. Произвольные выборки не поддерживаются. Да и текстовый SQL писать надо — неудобно. Кроме того датасеты очень громозкие. G>Гораздо удобнее список "записей" (неизменяемых структур со структурной эквивалентностью), но ни язык не поддерживает, ни средств отображения для таких структур нету. G>Может быть на базе следующего EF такое можно будет собрать. А сейчас с нуля создавать — дороговато будет.
Зато anemic, дальше некуда.
G>А куда методы оперирующие объектами A, B, C помещать? G>В отдельные сервисы, а значит вся "красота", за которую бъются приверженцы rich, теряется.
Ну вы и договорились до ручки ) Вы тут заявляете, что rich противоречит rich.
Нет, не подумайте, я нисколько не отказываюсь от сервисов, они бывают необходимы: например, инфраструктура. Т.е. я -- не отказываюсь от в меру anemic, а совмещаю А вот _вы_ -- радикально отказываетесь от логики в объектах ) В этом -- наша сила.
Re[19]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, meowth, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, meowth, Вы писали: G>>Да это вроде всем известно: rich прибивает БЛ к объктам, хранящим данные. M>Rich model не занимается _хранением _данных. Она отвечает за их представление и поведение. Хранение и транспорт -- это anemic/DTO. Попробуйте посмотреть с этой точки зрения.
Так что, данных внутри domain objects нету? Меня не философия беспокоит, а реализация.
Что вообще за манера такая — хреновость реализации заменять философией?
M>Вы смотрите с точки зрения данные + операции.
Любая программа состоит из данных и операций с этими данными.
M>Представьте себе ООСУБД. Не обсуждая минусы, с вашей точки зрения, она вообще существовать -- не может: ее факт существования просто противоречит реальности true anemic.
Это тут причем?
G>>А куда методы оперирующие объектами A, B, C помещать? G>>В отдельные сервисы, а значит вся "красота", за которую бъются приверженцы rich, теряется. M>Ну вы и договорились до ручки ) Вы тут заявляете, что rich противоречит rich.
Я не заявляю. Я вопросы задаю.
Фаулер кстати на такой вопрос отвечает очень уклончиво, а в DDD не отвечают вообще.
M>Нет, не подумайте, я нисколько не отказываюсь от сервисов, они бывают необходимы: например, инфраструктура. Т.е. я -- не отказываюсь от в меру anemic, а совмещаю
И получаете размазанную по куче слоев логику.
Хотя это еще зависит от точго что называть логикой
M>А вот _вы_ -- радикально отказываетесь от логики в объектах )
Поэтому я могу БЛ переиспользовать даже в бинарном виде в разных проектах (пример с видимостью для админа я приводил в соседней теме).
M>В этом -- наша сила.
В этом ваша слабость. Помещая логику работы с данными в объект с данными ты сразу лишаешь себя как повторного использования объектов, так и повторного использования логики.
Re[20]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, gandjustas, Вы писали:
G>Так что, данных внутри domain objects нету? Меня не философия беспокоит, а реализация. G>Что вообще за манера такая — хреновость реализации заменять философией?
Никакой философии, извините, если так показалось. Данные есть, но слово "хранятся" к ним не подходит. Давайте я попробую пояснить. С точки зрения anemic, данные хранятся в БД, потом их оттуда DTOят к коду, который их обрабатывает, потом они попадают в БД. С точки зрения Rich domain БД вообще не существует -- т.н. принцип persistence ignorance. Соответственная инфраструктура направлена на реализацию этого принципа. Данные никуда не надо транспортировать, хранить -- нужно только обеспечить их поведение, оркестрацию, если угодно.
M>>Вы смотрите с точки зрения данные + операции. G>Любая программа состоит из данных и операций с этими данными.
Выше, выше
M>>Представьте себе ООСУБД. Не обсуждая минусы, с вашей точки зрения, она вообще существовать -- не может: ее факт существования просто противоречит реальности true anemic. G>Это тут причем?
При том, что если согласно некоторой теории объекты не могут существовать, а они существуют, это значит, что в теории есть изъян.
G>>>А куда методы оперирующие объектами A, B, C помещать? G>>>В отдельные сервисы, а значит вся "красота", за которую бъются приверженцы rich, теряется. M>>Ну вы и договорились до ручки ) Вы тут заявляете, что rich противоречит rich. G>Я не заявляю. Я вопросы задаю. G>Фаулер кстати на такой вопрос отвечает очень уклончиво, а в DDD не отвечают вообще.
Методы помещаются или в сервисы инфраструктуры, или в объекты domain. При этом ничего не мешает иметь в domain такой объект, как report calculator.
M>>Нет, не подумайте, я нисколько не отказываюсь от сервисов, они бывают необходимы: например, инфраструктура. Т.е. я -- не отказываюсь от в меру anemic, а совмещаю G>И получаете размазанную по куче слоев логику. G>Хотя это еще зависит от точго что называть логикой
Согласно вашему определению бизнес-логика anemic вся также разбросана в сервисах.
M>>А вот _вы_ -- радикально отказываетесь от логики в объектах ) G>Поэтому я могу БЛ переиспользовать даже в бинарном виде в разных проектах (пример с видимостью для админа я приводил в соседней теме).
К сожалению, не встречал проекты на практике, где это понадобилось бы. Возможно, это тоже влияет на мою точку зрения.
M>>В этом -- наша сила. G>В этом ваша слабость. Помещая логику работы с данными в объект с данными ты сразу лишаешь себя как повторного использования объектов, так и повторного использования логики.
Я вообще-то говорил о том, что сила в использовании как anemic, так и domain, чего вы (гибрида) не приемлете совсем. А по вашему предложению у нас так -- новая задача, новый domain, переиспользовать-то и незачем.
Извините, на этом исчезаю до воскресенья. До свидания, спасибо.
Re[21]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, meowth, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Так что, данных внутри domain objects нету? Меня не философия беспокоит, а реализация. G>>Что вообще за манера такая — хреновость реализации заменять философией? M>Никакой философии, извините, если так показалось. Данные есть, но слово "хранятся" к ним не подходит. Давайте я попробую пояснить. С точки зрения anemic, данные хранятся в БД, потом их оттуда DTOят к коду, который их обрабатывает, потом они попадают в БД. С точки зрения Rich domain БД вообще не существует -- т.н. принцип persistence ignorance.
Не путай теплое с мягким. Во-первых в rich PI действует только на уровне методов классов. В другиз местах есть репозитарии и другие объекты, котообые обеспечивают доставание\запись данных.
M>Соответственная инфраструктура направлена на реализацию этого принципа.
Скажу по секрету, для anemic используется почти такая же инфраструктура.
M>Данные никуда не надо транспортировать, хранить -- нужно только обеспечить их поведение, оркестрацию, если угодно.
Поведение данных? Оригинально.
Интересно какие поведение у заказа? Или у карточки клиента?
А вот чтобы как-то работать с данными эти данные должны быть в каком-либо объекте, так что ханить кто-то их должен.
M>>>Представьте себе ООСУБД. Не обсуждая минусы, с вашей точки зрения, она вообще существовать -- не может: ее факт существования просто противоречит реальности true anemic. G>>Это тут причем? M>При том, что если согласно некоторой теории объекты не могут существовать, а они существуют, это значит, что в теории есть изъян.
Сам придумал какую-то теорию, теперь сам её опровергаешь.
G>>>>А куда методы оперирующие объектами A, B, C помещать? G>>>>В отдельные сервисы, а значит вся "красота", за которую бъются приверженцы rich, теряется. M>>>Ну вы и договорились до ручки ) Вы тут заявляете, что rich противоречит rich. G>>Я не заявляю. Я вопросы задаю. G>>Фаулер кстати на такой вопрос отвечает очень уклончиво, а в DDD не отвечают вообще. M>Методы помещаются или в сервисы инфраструктуры, или в объекты domain. При этом ничего не мешает иметь в domain такой объект, как report calculator.
Еще как мешает. В предметной области нету report calculator.
M>>>Нет, не подумайте, я нисколько не отказываюсь от сервисов, они бывают необходимы: например, инфраструктура. Т.е. я -- не отказываюсь от в меру anemic, а совмещаю G>>И получаете размазанную по куче слоев логику. G>>Хотя это еще зависит от точго что называть логикой M>Согласно вашему определению бизнес-логика anemic вся также разбросана в сервисах.
Не разбросана.
Это в rich логика может быть в domain object, root aggregate и в отдельном сервисе.
А самый кайф наступает когда какой-нить на вид безобидный метод типа AddItem у заказа начинает лезть в базу и поднимать другие айтемы для пересчета.
M>>>А вот _вы_ -- радикально отказываетесь от логики в объектах ) G>>Поэтому я могу БЛ переиспользовать даже в бинарном виде в разных проектах (пример с видимостью для админа я приводил в соседней теме). M>К сожалению, не встречал проекты на практике, где это понадобилось бы. Возможно, это тоже влияет на мою точку зрения.
M>>>В этом -- наша сила. G>>В этом ваша слабость. Помещая логику работы с данными в объект с данными ты сразу лишаешь себя как повторного использования объектов, так и повторного использования логики. M>Я вообще-то говорил о том, что сила в использовании как anemic, так и domain, чего вы (гибрида) не приемлете совсем.
И какая сила у domain?
M>А по вашему предложению у нас так -- новая задача, новый domain, переиспользовать-то и незачем.
Новый domain не означает новую логику. Если работаем с данными, то нам не важно по какой причине у нас есть понятие видимости, мы можем в любом использовать одну и ту же логику для получения видимых объектов, независимо от того что это за объекты.
Re[22]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, gandjustas, Вы писали:
M>>Никакой философии, извините, если так показалось. Данные есть, но слово "хранятся" к ним не подходит. Давайте я попробую пояснить. С точки зрения anemic, данные хранятся в БД, потом их оттуда DTOят к коду, который их обрабатывает, потом они попадают в БД. С точки зрения Rich domain БД вообще не существует -- т.н. принцип persistence ignorance. G>Не путай теплое с мягким. Во-первых в rich PI действует только на уровне методов классов.
"действует только на уровне методов классов" -- это как? о_О Вы точно знакомы с rich model?
G>В другиз местах есть репозитарии и другие объекты, котообые обеспечивают доставание\запись данных.
В том то и дело, что вы смотрите на это, как на "доставание-запись данных" из персистентного источника и перемещение их в некотором контейнере (anemic DTO) к сервисам. Еще раз говорю, попробуйте взглянуть с другой стороны. В rich данные не путешествуют к коду, который их обрабатывает. Здесь они сами есть и объекты, и поведение, причем представленные так, как это видит domain expert. С точки зрения бизнес-скрипта есть объекты, которые существуют "вечно" (идеальная ситуация). Это уже забота инфраструктуры -- поднять их из хранилища или заперсистить, и в какой момент. То, что есть repository, не значит, что они там сохраняются, понимаете. Repository -- это вообще антипаттерн rich, и никто не говорит, что они ведут в БД. PI, ё-моё, вы как будто издеваетесь!
M>>Соответственная инфраструктура направлена на реализацию этого принципа. G>Скажу по секрету, для anemic используется почти такая же инфраструктура.
Но при этом LL вам мешает, а Identity Map не нужен совсем -- все данные value-object. Что же тогда в anemic от инфраструктуры остается?
M>>Данные никуда не надо транспортировать, хранить -- нужно только обеспечить их поведение, оркестрацию, если угодно. G>Поведение данных? Оригинально. G>Интересно какие поведение у заказа? Или у карточки клиента?
Уточните у них при личной встрече. Шутка Какое надо, такое и будет. Вы же понимаете, что я не буду счас это рассказывать?
G>А вот чтобы как-то работать с данными эти данные должны быть в каком-либо объекте, так что хранить кто-то их должен.
Читайте выше про PI. Вообще читайте про PI.
M>>>>Представьте себе ООСУБД. Не обсуждая минусы, с вашей точки зрения, она вообще существовать -- не может: ее факт существования просто противоречит реальности true anemic. G>>>Это тут причем? M>>При том, что если согласно некоторой теории объекты не могут существовать, а они существуют, это значит, что в теории есть изъян. G> G>Сам придумал какую-то теорию, теперь сам её опровергаешь.
Нет, это с точки зрения anemic в вашей интерпретации -- есть данные, есть plain old data контейнеры для них. А вот в ООСУБД все не так, там нет ни того, ни другого. Значит, с точки зрения anemic оно не может существовать.
M>>Методы помещаются или в сервисы инфраструктуры, или в объекты domain. При этом ничего не мешает иметь в domain такой объект, как report calculator. G>Еще как мешает. В предметной области нету report calculator.
Бгг, это вы мне будете говорить, есть там или нет? Мой domain, помещаю, что хочу. У меня -- есть.
Да, вкупе с вашим заявлением, что проектировать надо не в объектах, а в функциях, этот приказ мне убрать оттуда report calculator звучит вообще весело. Я, конечно, понимаю, что вы уже наигрались с ООП и рветесь в бой на функциональные языки, но .. может, оставите их в стороне, вне темы anemic?
G>А самый кайф наступает когда какой-нить на вид безобидный метод типа AddItem у заказа начинает лезть в базу G>и поднимать другие айтемы для пересчета.
Если эти данные лежат в БД, и больше нигде, и они нужны, то хоть в anemic, хоть в rich их придется оттуда вынуть. Не вижу, чем тут одно уступает другому. Однако, в моей ситуации ~85-95% данных оказываются в объектном кеше (это цифры из реальной программы). Readonly справочники туда ложатся сразу после прогрева кеша. При этом я не написал для этого ни строки -- все делает инфраструктура (NHibernate + Spring.net)
Пример из жизни: однажды у нас пропало соединение с БД. Логика еще минут 30-40 работала из кеша. В проектируемой системе сейчас 8G memcached на 4х машинах, занятые обычно процентов на 15-40.
M>>Я вообще-то говорил о том, что сила в использовании как anemic, так и domain, чего вы (гибрида) не приемлете совсем. G>И какая сила у domain?
Опять 25 ) Не буду пересказывать Фаулера, потому что не хочу опять обсуждать мое понимание его письмен )
M>>А по вашему предложению у нас так -- новая задача, новый domain, переиспользовать-то и незачем. G>Новый domain не означает новую логику. Если работаем с данными, то нам не важно по какой причине у нас есть понятие видимости, мы можем в любом использовать одну и ту же логику для получения видимых объектов, независимо от того что это за объекты.
Еще раз говорю, это все красиво только на словах. В жизни не видел, чтобы бизнес-логику использовали повторно. Наоборот, возьмите в пример хоть 1С как бизнес-систему — при подготовке новой конфигурации вы переписываете именно бизнес-логику, а не что-то другое. Так что тут очень и очень спорно ))
Re[23]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, meowth, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
M>>>Никакой философии, извините, если так показалось. Данные есть, но слово "хранятся" к ним не подходит. Давайте я попробую пояснить. С точки зрения anemic, данные хранятся в БД, потом их оттуда DTOят к коду, который их обрабатывает, потом они попадают в БД. С точки зрения Rich domain БД вообще не существует -- т.н. принцип persistence ignorance. G>>Не путай теплое с мягким. Во-первых в rich PI действует только на уровне методов классов. M>"действует только на уровне методов классов" -- это как? о_О Вы точно знакомы с rich model?
Конечно знаком. PI — это не только plain objects, это еще и идеология, котороая говорит что работа приложения не зависит от сохранения данных.
На самом деле таким свойстом обладает только очень малая часть логики, которая в rich как раз заключается в методы domain objects.
G>>В другиз местах есть репозитарии и другие объекты, котообые обеспечивают доставание\запись данных. M>В том то и дело, что вы смотрите на это, как на "доставание-запись данных" из персистентного источника и перемещение их в некотором контейнере (anemic DTO) к сервисам.
В любой программе работа с персистентными данными заключается в двух принципиально разных операциях: получение некоторых данных из хранилища и изменение данных в хранилище. Ничего другого придумать нельзя.
M>Еще раз говорю, попробуйте взглянуть с другой стороны. В rich данные не путешествуют к коду, который их обрабатывает. Здесь они сами есть и объекты, и поведение, причем представленные так, как это видит domain expert.
Еще раз, какое поведение у записи о клиенте? Или у заказа?
Может конечно domain expert курит что-то, но такой случай рассматривать не стоит.
Думаете domain expertу становится легче от объектной нотации, для тех объектов, у которых в реальном мире нету поведения?
M>С точки зрения бизнес-скрипта есть объекты, которые существуют "вечно" (идеальная ситуация). Это уже забота инфраструктуры -- поднять их из хранилища или заперсистить, и в какой момент. То, что есть repository, не значит, что они там сохраняются, понимаете. Repository -- это вообще антипаттерн rich, и никто не говорит, что они ведут в БД. PI, ё-моё, вы как будто издеваетесь!
Ну да, мечта идиота — объекты, которые сами непонятно как и непонятно где сохраняются.
Вообще-то такая абстракция течет как дырявый друшлаг.
M>>>Соответственная инфраструктура направлена на реализацию этого принципа. G>>Скажу по секрету, для anemic используется почти такая же инфраструктура. M>Но при этом LL вам мешает, а Identity Map не нужен совсем -- все данные value-object. Что же тогда в anemic от инфраструктуры остается?
Маппер и, самое главное, динамическое построение запросов средаствами типа Linq.
M>>>Данные никуда не надо транспортировать, хранить -- нужно только обеспечить их поведение, оркестрацию, если угодно. G>>Поведение данных? Оригинально. G>>Интересно какие поведение у заказа? Или у карточки клиента? M>Уточните у них при личной встрече. Шутка Какое надо, такое и будет. Вы же понимаете, что я не буду счас это рассказывать?
Ну так не интересно. Давайте всетаки по конкретным примерам, а то теоретизировать можно бесконечно долго.
Вот есть интернет-магазин. Есть товары, разбитые по категориям, юзеры оставляют заказы, состоящие из нескольких позиций. Где тут будет поведение?
G>>А вот чтобы как-то работать с данными эти данные должны быть в каком-либо объекте, так что хранить кто-то их должен. M>Читайте выше про PI. Вообще читайте про PI.
Я читал про PI еще 5 лет назад, не вдохновило.
M>>>>>Представьте себе ООСУБД. Не обсуждая минусы, с вашей точки зрения, она вообще существовать -- не может: ее факт существования просто противоречит реальности true anemic. G>>>>Это тут причем? M>>>При том, что если согласно некоторой теории объекты не могут существовать, а они существуют, это значит, что в теории есть изъян. G>> G>>Сам придумал какую-то теорию, теперь сам её опровергаешь. M>Нет, это с точки зрения anemic в вашей интерпретации -- есть данные, есть plain old data контейнеры для них. А вот в ООСУБД все не так, там нет ни того, ни другого. Значит, с точки зрения anemic оно не может существовать.
Заметьте, я вообще ничего не говорил по этому поводу
M>>>Методы помещаются или в сервисы инфраструктуры, или в объекты domain. При этом ничего не мешает иметь в domain такой объект, как report calculator. G>>Еще как мешает. В предметной области нету report calculator. M>Бгг, это вы мне будете говорить, есть там или нет? Мой domain, помещаю, что хочу. У меня -- есть.
Только domain expert вас не поймет. Да и нету в предметной области report calculator, ни в какой.
Или будет контрпример?
G>>А самый кайф наступает когда какой-нить на вид безобидный метод типа AddItem у заказа начинает лезть в базу G>>и поднимать другие айтемы для пересчета. M>Если эти данные лежат в БД, и больше нигде, и они нужны, то хоть в anemic, хоть в rich их придется оттуда вынуть. Не вижу, чем тут одно уступает другому.
Угу, только возникает вопрос где эти данные вытягиваются.
Если это безобидный на вид метод AddItem, то сразу же проблема. Программист по незнанию может воспользоваться таким методом где не надо и получить бяку.
M>Однако, в моей ситуации ~85-95% данных оказываются в объектном кеше (это цифры из реальной программы). Readonly справочники туда ложатся сразу после прогрева кеша. При этом я не написал для этого ни строки -- все делает инфраструктура (NHibernate + Spring.net)
Наличие объектного кеша большой костыль. Кстати, как когерентность кеша обеспечивается?
M>Пример из жизни: однажды у нас пропало соединение с БД. Логика еще минут 30-40 работала из кеша. В проектируемой системе сейчас 8G memcached на 4х машинах, занятые обычно процентов на 15-40.
Скока скока? Гиг-два в кеше? А размер базы какой?
Я-то по наивности делаю так чтобы на shared-хостинге решение развернуть можно было.
M>>>Я вообще-то говорил о том, что сила в использовании как anemic, так и domain, чего вы (гибрида) не приемлете совсем. G>>И какая сила у domain? M>Опять 25 ) Не буду пересказывать Фаулера, потому что не хочу опять обсуждать мое понимание его письмен )
Не надо фаулера пересказываеть, его тут все читали. Свое мнение, основанное не на утверждении что это "больше ООП".
M>>>А по вашему предложению у нас так -- новая задача, новый domain, переиспользовать-то и незачем. G>>Новый domain не означает новую логику. Если работаем с данными, то нам не важно по какой причине у нас есть понятие видимости, мы можем в любом использовать одну и ту же логику для получения видимых объектов, независимо от того что это за объекты. M>Еще раз говорю, это все красиво только на словах. В жизни не видел, чтобы бизнес-логику использовали повторно.
А я видел, и использую. и мне для этого не надо использовать memcached на 4 машинах.
Re[24]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, gandjustas, Вы писали:
M>>"действует только на уровне методов классов" -- это как? о_О Вы точно знакомы с rich model? G>Конечно знаком. PI — это не только plain objects, это еще и идеология, котороая говорит что работа приложения не зависит от сохранения данных. G>На самом деле таким свойстом обладает только очень малая часть логики, которая в rich как раз заключается в методы domain objects.
Я и не говорил про pdo. Т.е. по вашему, идеология есть, но она все равно нигде не проявляется, потому что ее 5%, а остальные 95% -- сервисный код, где PI не доступен? Видимо, у меня неправильный проект -- там логики процентов 70. А если не учитывать самописные велосипеды (наследие такое, к сожалению), то и побольше.
G>>>В другиз местах есть репозитарии и другие объекты, котообые обеспечивают доставание\запись данных. M>>В том то и дело, что вы смотрите на это, как на "доставание-запись данных" из персистентного источника и перемещение их в некотором контейнере (anemic DTO) к сервисам. G>В любой программе работа с персистентными данными заключается в двух принципиально разных операциях: получение некоторых данных из хранилища и изменение данных в хранилище.
Это лично ваше мнение? Реквестирую пруфлинк.
G>Ничего другого придумать нельзя.
Видимо, у меня совсем другая программа, или я придумал что-то 3ье ( Эти ваши "принципиальные" операции у меня находятся в слое сервисов, и занимают 1% от кода, а то и меньше.
G>Еще раз, какое поведение у записи о клиенте? Или у заказа? G>Может конечно domain expert курит что-то, но такой случай рассматривать не стоит. G>Думаете domain expertу становится легче от объектной нотации, для тех объектов, у которых в реальном мире нету поведения?
При чем здесь "нет поведения"? Поведение есть, оно и реализуется в логике. Другое дело, что это -- синтетический объект, но с его привлечением с этим функционалом можно работать в терминах домена.
G>Ну да, мечта идиота — объекты, которые сами непонятно как и непонятно где сохраняются. G>Вообще-то такая абстракция течет как дырявый друшлаг.
О**енно обоснованные аргументы. Ссылку на доказательство.
Еще раз говорю, репозиторий лежит в сервисном слое (200 строк кода), и как и что сохраняется, понятно. Остальное -- вне него, им он не нужен.
M>>Но при этом LL вам мешает, а Identity Map не нужен совсем -- все данные value-object. Что же тогда в anemic от инфраструктуры остается? G>Маппер и, самое главное, динамическое построение запросов средаствами типа Linq.
Хм. если это -- главное, то у вас, видимо, большая часть кода -- сервисный слой, и вам rich не подойдет.
G>>>Интересно какие поведение у заказа? Или у карточки клиента? M>>Уточните у них при личной встрече. Шутка Какое надо, такое и будет. Вы же понимаете, что я не буду счас это рассказывать? G>Ну так не интересно. Давайте всетаки по конкретным примерам, а то теоретизировать можно бесконечно долго. G>Вот есть интернет-магазин. Есть товары, разбитые по категориям, юзеры оставляют заказы, состоящие из нескольких позиций. Где тут будет поведение?
Хы. Вы придумали -- вы и решайте.
G>Я читал про PI еще 5 лет назад, не вдохновило.
Ну увы, опять же )
М>>Нет, это с точки зрения anemic в вашей интерпретации -- есть данные, есть plain old data контейнеры для них. А вот в ООСУБД все не так, там нет ни того, ни другого. Значит, с точки зрения anemic оно не может существовать. G>Заметьте, я вообще ничего не говорил по этому поводу
Вы говорили про "2 принципиально разные операции, Ничего другого придумать нельзя." выше. В ООСУБД этого нет, и не надо. Надо же, придумали
M>>Бгг, это вы мне будете говорить, есть там или нет? Мой domain, помещаю, что хочу. У меня -- есть. G>Только domain expert вас не поймет. Да и нету в предметной области report calculator, ни в какой. G>Или будет контрпример?
Только что был, с report calculator. В реальном проекте ситуация не сильно отличается, только там не report, а statistics.
M>>Однако, в моей ситуации ~85-95% данных оказываются в объектном кеше (это цифры из реальной программы). Readonly справочники туда ложатся сразу после прогрева кеша. При этом я не написал для этого ни строки -- все делает инфраструктура (NHibernate + Spring.net) G>Наличие объектного кеша большой костыль.
Ваше мнение. Пруфлинк, или неправда.
G>Кстати, как когерентность кеша обеспечивается?
Этим занимается инфраструктура (NHibernate) в моем случае. Из некоторых способов -- тем, что объекты там хранятся в "разобранном" состоянии, маркировкой областей кеша, корректной обработкой транзакций. За остальными способами отсылаю к исходникам Nhibernate.
M>>Пример из жизни: однажды у нас пропало соединение с БД. Логика еще минут 30-40 работала из кеша. В проектируемой системе сейчас 8G memcached на 4х машинах, занятые обычно процентов на 15-40. G> G>Скока скока? Гиг-два в кеше? А размер базы какой? G>Я-то по наивности делаю так чтобы на shared-хостинге решение развернуть можно было.
Размер базы 50G. А вы много чего делаете по наивности; например, паясничаете строкой выше.
M>>Опять 25 ) Не буду пересказывать Фаулера, потому что не хочу опять обсуждать мое понимание его письмен ) G>Не надо фаулера пересказываеть, его тут все читали. Свое мнение, основанное не на утверждении что это "больше ООП".
Вкратце, чистота domain logic, код ближе к данным, с которыми он работает; далее, мне так привычнее )
G>А я видел, и использую. и мне для этого не надо использовать memcached на 4 машинах.
Не придирайтесь. Пример с кешем из реального проекта иллюстрировал то, что "на каждый чих ходить в БД" -- это неверное представление о ситуации.
Вобщем, так Я так понимаю, доказать в теории вам невозможно -- потому что необходимо ответить на все ваши контраргументы, которые у вам, похоже, не закончатся. А примеры из практики вы объявляете смешными и "незжизненными".
Давайте прекратим этот спор (ну или вы ответите, и тогда прекратим )
Re[25]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, meowth, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
M>>>"действует только на уровне методов классов" -- это как? о_О Вы точно знакомы с rich model? G>>Конечно знаком. PI — это не только plain objects, это еще и идеология, котороая говорит что работа приложения не зависит от сохранения данных. G>>На самом деле таким свойстом обладает только очень малая часть логики, которая в rich как раз заключается в методы domain objects. M>Я и не говорил про pdo. Т.е. по вашему, идеология есть, но она все равно нигде не проявляется, потому что ее 5%, а остальные 95% -- сервисный код, где PI не доступен?
Нет. Любой код, работающюй с данными все равно дожен как-то получать данные и сохранять их.
G>>>>В другиз местах есть репозитарии и другие объекты, котообые обеспечивают доставание\запись данных. M>>>В том то и дело, что вы смотрите на это, как на "доставание-запись данных" из персистентного источника и перемещение их в некотором контейнере (anemic DTO) к сервисам. G>>В любой программе работа с персистентными данными заключается в двух принципиально разных операциях: получение некоторых данных из хранилища и изменение данных в хранилище. M>Это лично ваше мнение? Реквестирую пруфлинк.
Это очевидно.
G>>Ничего другого придумать нельзя. M>Видимо, у меня совсем другая программа, или я придумал что-то 3ье ( Эти ваши "принципиальные" операции у меня находятся в слое сервисов, и занимают 1% от кода, а то и меньше.
Ну и что третье?
G>>Еще раз, какое поведение у записи о клиенте? Или у заказа? G>>Может конечно domain expert курит что-то, но такой случай рассматривать не стоит. G>>Думаете domain expertу становится легче от объектной нотации, для тех объектов, у которых в реальном мире нету поведения? M>При чем здесь "нет поведения"? Поведение есть, оно и реализуется в логике. Другое дело, что это -- синтетический объект, но с его привлечением с этим функционалом можно работать в терминах домена.
Ух ты, сервисы получились.
G>>Ну да, мечта идиота — объекты, которые сами непонятно как и непонятно где сохраняются. G>>Вообще-то такая абстракция течет как дырявый друшлаг. M>О**енно обоснованные аргументы. Ссылку на доказательство.
Data != Objects — это аксиома, независимо от способа представления этих самых данных.
Доказательством является саом наличие persistance инфрастуктуры с Identity map, Unit of work и прочими паттернами.
Пока еще никому не удалось изобрести БД, которая отдает объекты (имеенно объекты, а не копию данных) с ссылочной эквивалентностью и без необходмости дополнительного преобразование, и чтобы при этом не было необходимости явно сохранять изменения.
Кстати как в таком случае будет поддерживаться транзакционность? Есть подозрение что вообще никак.
И даже если изобретут, но нафиг оно никому надо не будет, ибо данные по своей природе реляционны, а не объектны.
M>Еще раз говорю, репозиторий лежит в сервисном слое (200 строк кода), и как и что сохраняется, понятно. Остальное -- вне него, им он не нужен.
Сути это не меняет. Все операции с данными сводятся к получению некоторых данных или их изменнеию.
M>>>Но при этом LL вам мешает, а Identity Map не нужен совсем -- все данные value-object. Что же тогда в anemic от инфраструктуры остается? G>>Маппер и, самое главное, динамическое построение запросов средаствами типа Linq. M>Хм. если это -- главное, то у вас, видимо, большая часть кода -- сервисный слой, и вам rich не подойдет.
У меня вся бизнес-логика в сервисах.
G>>>>Интересно какие поведение у заказа? Или у карточки клиента? M>>>Уточните у них при личной встрече. Шутка Какое надо, такое и будет. Вы же понимаете, что я не буду счас это рассказывать? G>>Ну так не интересно. Давайте всетаки по конкретным примерам, а то теоретизировать можно бесконечно долго. G>>Вот есть интернет-магазин. Есть товары, разбитые по категориям, юзеры оставляют заказы, состоящие из нескольких позиций. Где тут будет поведение? M>Хы. Вы придумали -- вы и решайте.
Я уже десяток раз решалю Мне интересно как DDD в таком случае заработает.
М>>>Нет, это с точки зрения anemic в вашей интерпретации -- есть данные, есть plain old data контейнеры для них. А вот в ООСУБД все не так, там нет ни того, ни другого. Значит, с точки зрения anemic оно не может существовать. G>>Заметьте, я вообще ничего не говорил по этому поводу M>Вы говорили про "2 принципиально разные операции, Ничего другого придумать нельзя." выше. В ООСУБД этого нет, и не надо. Надо же, придумали
Ну, ссылку на такую ООСУБД в студию. Естественно она должна быть многопользовательской и поддерживать ACID трензакции.
M>>>Бгг, это вы мне будете говорить, есть там или нет? Мой domain, помещаю, что хочу. У меня -- есть. G>>Только domain expert вас не поймет. Да и нету в предметной области report calculator, ни в какой. G>>Или будет контрпример? M>Только что был, с report calculator. В реальном проекте ситуация не сильно отличается, только там не report, а statistics.
И какой части предметной области он соответсвует?
M>>>Однако, в моей ситуации ~85-95% данных оказываются в объектном кеше (это цифры из реальной программы). Readonly справочники туда ложатся сразу после прогрева кеша. При этом я не написал для этого ни строки -- все делает инфраструктура (NHibernate + Spring.net) G>>Наличие объектного кеша большой костыль. M>Ваше мнение. Пруфлинк, или неправда.
Пруф заключается в том, что есть системы которым не нужнен огромный кеш для нормально работы.
M>>>Опять 25 ) Не буду пересказывать Фаулера, потому что не хочу опять обсуждать мое понимание его письмен ) G>>Не надо фаулера пересказываеть, его тут все читали. Свое мнение, основанное не на утверждении что это "больше ООП". M>Вкратце, чистота domain logic, код ближе к данным, с которыми он работает; далее, мне так привычнее )
Ключевое выделил.
domain logic чистотой не обладает, так как задейтсован LL, который может давать эффекты сказывающиеся на производительности.
Код ближе к данным — вероятнее всего нарушение SRP.
G>>А я видел, и использую. и мне для этого не надо использовать memcached на 4 машинах. M>Не придирайтесь. Пример с кешем из реального проекта иллюстрировал то, что "на каждый чих ходить в БД" -- это неверное представление о ситуации.
Ну можно ходить в распределенный кеш. Который тоже является своего рода СУБД, только гораздо более слабой.
Единственное его преимущество, то что он быстрый "снаружи".
M>Вобщем, так Я так понимаю, доказать в теории вам невозможно -- потому что необходимо ответить на все ваши контраргументы, которые у вам, похоже, не закончатся. А примеры из практики вы объявляете смешными и "незжизненными".
Не надо в теории доказывать, приведите пример, причет полный, без сокрытия самых интересных частей.
Re[26]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, gandjustas, Вы писали:
M>>Я и не говорил про pdo. Т.е. по вашему, идеология есть, но она все равно нигде не проявляется, потому что ее 5%, а остальные 95% -- сервисный код, где PI не доступен? G>Нет. Любой код, работающюй с данными все равно дожен как-то получать данные и сохранять их.
Не спорю. Другое дело, что он может это делать сам, а может полагаться на инфраструктуру.
G>>>В любой программе работа с персистентными данными заключается в двух принципиально разных операциях: получение некоторых данных из хранилища и изменение данных в хранилище. M>>Это лично ваше мнение? Реквестирую пруфлинк. G>Это очевидно.
Без комментариев.
G>>>Ничего другого придумать нельзя. M>>Видимо, у меня совсем другая программа, или я придумал что-то 3ье ( Эти ваши "принципиальные" операции у меня находятся в слое сервисов, и занимают 1% от кода, а то и меньше. G>Ну и что третье?
Третье то, что коду бизнес-логики абсолюьно пофиг, что данные лежат где-то в БД. Их доставкой занимается инфраструктура и 1 (один сервис), называемый репозиторием. Причем это делается в режиме push, т.е. бизнес-логике вообще не надо никуда обращаться.
G>>>Еще раз, какое поведение у записи о клиенте? Или у заказа? G>>>Может конечно domain expert курит что-то, но такой случай рассматривать не стоит. G>>>Думаете domain expertу становится легче от объектной нотации, для тех объектов, у которых в реальном мире нету поведения? M>>При чем здесь "нет поведения"? Поведение есть, оно и реализуется в логике. Другое дело, что это -- синтетический объект, но с его привлечением с этим функционалом можно работать в терминах домена. G>Ух ты, сервисы получились.
Так никто не говорит, что от них кто-то собрался оказываться. Repository -- это типичный сервис. Но domain expertу на него пофик.
G>>>Ну да, мечта идиота — объекты, которые сами непонятно как и непонятно где сохраняются. G>>>Вообще-то такая абстракция течет как дырявый друшлаг. M>>О**енно обоснованные аргументы. Ссылку на доказательство. G>Data != Objects — это аксиома, независимо от способа представления этих самых данных. G>Доказательством является саом наличие persistance инфрастуктуры с Identity map, Unit of work и прочими паттернами.
Не спорю. Но я не хочу работать с ними как с plain data, поэтому и есть эта инфраструктура.
G>Пока еще никому не удалось изобрести БД, которая отдает объекты (имеенно объекты, а не копию данных) с ссылочной эквивалентностью и без необходмости дополнительного преобразование, и чтобы при этом не было необходимости явно сохранять изменения.
В Smalltalk загляните -- там это есть.
G>Кстати как в таком случае будет поддерживаться транзакционность? Есть подозрение что вообще никак. G>И даже если изобретут, но нафиг оно никому надо не будет, ибо данные по своей природе реляционны, а не объектны.
Ваше мнение.
M>>Еще раз говорю, репозиторий лежит в сервисном слое (200 строк кода), и как и что сохраняется, понятно. Остальное -- вне него, им он не нужен. G>Сути это не меняет. Все операции с данными сводятся к получению некоторых данных или их изменнеию.
Ух ты, надо же. Как это агитирует за anemic, я так и не понял.
M>>>>Но при этом LL вам мешает, а Identity Map не нужен совсем -- все данные value-object. Что же тогда в anemic от инфраструктуры остается? G>>>Маппер и, самое главное, динамическое построение запросов средаствами типа Linq. M>>Хм. если это -- главное, то у вас, видимо, большая часть кода -- сервисный слой, и вам rich не подойдет. G>У меня вся бизнес-логика в сервисах.
Интересный подход. У меня -- не так.
G>>>>>Интересно какие поведение у заказа? Или у карточки клиента? M>>>>Уточните у них при личной встрече. Шутка Какое надо, такое и будет. Вы же понимаете, что я не буду счас это рассказывать? G>>>Ну так не интересно. Давайте всетаки по конкретным примерам, а то теоретизировать можно бесконечно долго. G>>>Вот есть интернет-магазин. Есть товары, разбитые по категориям, юзеры оставляют заказы, состоящие из нескольких позиций. Где тут будет поведение? M>>Хы. Вы придумали -- вы и решайте. G>Я уже десяток раз решалю Мне интересно как DDD в таком случае заработает.
Я не стану вам это объяснять, тем более здесь. Сами понимаете, почему -- прикручивать туда различные аспекты можно бесконечно, а решать ваши задачи я не хочу. У меня все работает
М>>>>Нет, это с точки зрения anemic в вашей интерпретации -- есть данные, есть plain old data контейнеры для них. А вот в ООСУБД все не так, там нет ни того, ни другого. Значит, с точки зрения anemic оно не может существовать. G>>>Заметьте, я вообще ничего не говорил по этому поводу M>>Вы говорили про "2 принципиально разные операции, Ничего другого придумать нельзя." выше. В ООСУБД этого нет, и не надо. Надо же, придумали G>Ну, ссылку на такую ООСУБД в студию. Естественно она должна быть многопользовательской и поддерживать ACID трензакции.
Db4o в режиме "remote server"
M>>>>Бгг, это вы мне будете говорить, есть там или нет? Мой domain, помещаю, что хочу. У меня -- есть. G>>>Только domain expert вас не поймет. Да и нету в предметной области report calculator, ни в какой. G>>>Или будет контрпример? M>>Только что был, с report calculator. В реальном проекте ситуация не сильно отличается, только там не report, а statistics. G>И какой части предметной области он соответсвует?
Вам в каких единицах отмерять? Видимо, я не понял вопроса.
M>>>>Однако, в моей ситуации ~85-95% данных оказываются в объектном кеше (это цифры из реальной программы). Readonly справочники туда ложатся сразу после прогрева кеша. При этом я не написал для этого ни строки -- все делает инфраструктура (NHibernate + Spring.net) G>>>Наличие объектного кеша большой костыль. M>>Ваше мнение. Пруфлинк, или неправда. G>Пруф заключается в том, что есть системы которым не нужнен огромный кеш для нормально работы.
Отличный пруф, продолжайте дальше. Есть системы, которым и БД не нужна. Про "огромный кеш" еще можно поспорить.
M>>>>Опять 25 ) Не буду пересказывать Фаулера, потому что не хочу опять обсуждать мое понимание его письмен ) G>>>Не надо фаулера пересказываеть, его тут все читали. Свое мнение, основанное не на утверждении что это "больше ООП". M>>Вкратце, чистота domain logic, код ближе к данным, с которыми он работает; далее, мне так привычнее ) G>Ключевое выделил. G>domain logic чистотой не обладает, так как задейтсован LL, который может давать эффекты сказывающиеся на производительности. G>Код ближе к данным — вероятнее всего нарушение SRP.
Ваше мнение. Тогда и ООП -- нарушение SRP из ООП.
G>>>А я видел, и использую. и мне для этого не надо использовать memcached на 4 машинах. M>>Не придирайтесь. Пример с кешем из реального проекта иллюстрировал то, что "на каждый чих ходить в БД" -- это неверное представление о ситуации. G>Ну можно ходить в распределенный кеш. Который тоже является своего рода СУБД, только гораздо более слабой. G>Единственное его преимущество, то что он быстрый "снаружи".
Я и иллюстрировал вам распределенный кеш. Преимущество -- что не загибается БД на выборках, а сами выборки -- в 10-100 раз быстрее
G>Не надо в теории доказывать, приведите пример, причет полный, без сокрытия самых интересных частей.
Хорошо, несколько позже приведу.
Re[25]: Архитектура приложения с несколькими клиентами и одн
M>>>Пример из жизни: однажды у нас пропало соединение с БД. Логика еще минут 30-40 работала из кеша. В проектируемой системе сейчас 8G memcached на 4х машинах, занятые обычно процентов на 15-40. G>> G>>Скока скока? Гиг-два в кеше? А размер базы какой? G>>Я-то по наивности делаю так чтобы на shared-хостинге решение развернуть можно было. M>Размер базы 50G. А вы много чего делаете по наивности; например, паясничаете строкой выше.
ИМХО этим все сказано, кто-то делает сайты для е-комерс, по три десятка на неделю. А кто-то таки делает корпоративный приложения. У нас опции шаред хостинга даже в теории нема. Наивно предполагать что человек педалящий первое может чему-то научить человека педалящего второе.
Здравствуйте, meowth, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
M>>>Я и не говорил про pdo. Т.е. по вашему, идеология есть, но она все равно нигде не проявляется, потому что ее 5%, а остальные 95% -- сервисный код, где PI не доступен? G>>Нет. Любой код, работающюй с данными все равно дожен как-то получать данные и сохранять их. M>Не спорю. Другое дело, что он может это делать сам, а может полагаться на инфраструктуру.
Все равно надо как-то объясниить инфраструктуре когда получать объекты и когда сохранять изменения.
G>>>>Ничего другого придумать нельзя. M>>>Видимо, у меня совсем другая программа, или я придумал что-то 3ье ( Эти ваши "принципиальные" операции у меня находятся в слое сервисов, и занимают 1% от кода, а то и меньше. G>>Ну и что третье? M>Третье то, что коду бизнес-логики абсолюьно пофиг, что данные лежат где-то в БД. Их доставкой занимается инфраструктура и 1 (один сервис), называемый репозиторием. Причем это делается в режиме push, т.е. бизнес-логике вообще не надо никуда обращаться.
Пример кода в студию. Даже интересно как такое выгялдит.
G>>>>Еще раз, какое поведение у записи о клиенте? Или у заказа? G>>>>Может конечно domain expert курит что-то, но такой случай рассматривать не стоит. G>>>>Думаете domain expertу становится легче от объектной нотации, для тех объектов, у которых в реальном мире нету поведения? M>>>При чем здесь "нет поведения"? Поведение есть, оно и реализуется в логике. Другое дело, что это -- синтетический объект, но с его привлечением с этим функционалом можно работать в терминах домена. G>>Ух ты, сервисы получились. M>Так никто не говорит, что от них кто-то собрался оказываться. Repository -- это типичный сервис. Но domain expertу на него пофик.
А причем тут repository? Вот есть у нас объекта заказа. У него очевидно нету поведения. Кто будет заниматтся созданием заказа?
G>>>>Ну да, мечта идиота — объекты, которые сами непонятно как и непонятно где сохраняются. G>>>>Вообще-то такая абстракция течет как дырявый друшлаг. M>>>О**енно обоснованные аргументы. Ссылку на доказательство. G>>Data != Objects — это аксиома, независимо от способа представления этих самых данных. G>>Доказательством является саом наличие persistance инфрастуктуры с Identity map, Unit of work и прочими паттернами. M>Не спорю. Но я не хочу работать с ними как с plain data, поэтому и есть эта инфраструктура.
Инфраструктура пытается скрыть факт, что это данные, а не объекты. Причем очень несупешно. Особенно это заметно при множестве параллельных операций.
Сторонники anemic как раз утверждают что чработать с данными как с данными — гораздо более правильный подход. Меньше дырявых асбтракций, больше возможностей, менее многословный и менее связный код получается.
G>>Пока еще никому не удалось изобрести БД, которая отдает объекты (имеенно объекты, а не копию данных) с ссылочной эквивалентностью и без необходмости дополнительного преобразование, и чтобы при этом не было необходимости явно сохранять изменения. M>В Smalltalk загляните -- там это есть.
Ссылку?
M>>>Еще раз говорю, репозиторий лежит в сервисном слое (200 строк кода), и как и что сохраняется, понятно. Остальное -- вне него, им он не нужен. G>>Сути это не меняет. Все операции с данными сводятся к получению некоторых данных или их изменнеию. M>Ух ты, надо же. Как это агитирует за anemic, я так и не понял.
Никак. Это просто чтобы понимали что все операции с данными сводятся к этим двум сценариям. И как раз более явное выражение изменения данных гораздо эффективнее работает и гораздо больше пишется, чем работа с данными в стиле ООП.
G>>>>>>Интересно какие поведение у заказа? Или у карточки клиента? M>>>>>Уточните у них при личной встрече. Шутка Какое надо, такое и будет. Вы же понимаете, что я не буду счас это рассказывать? G>>>>Ну так не интересно. Давайте всетаки по конкретным примерам, а то теоретизировать можно бесконечно долго. G>>>>Вот есть интернет-магазин. Есть товары, разбитые по категориям, юзеры оставляют заказы, состоящие из нескольких позиций. Где тут будет поведение? M>>>Хы. Вы придумали -- вы и решайте. G>>Я уже десяток раз решалю Мне интересно как DDD в таком случае заработает.http://www.rsdn.ru/forum/NewMsg.aspx?mid=3411004
M>Я не стану вам это объяснять, тем более здесь. Сами понимаете, почему -- прикручивать туда различные аспекты можно бесконечно, а решать ваши задачи я не хочу. У меня все работает
Ну как работает приведите пример требований и решение с помощью DDD.
А потом разберем посмотрим как оно будет в anemic и ответим на несколкьо "что если", чтобы оценить расширяемостиь решения.
М>>>>>Нет, это с точки зрения anemic в вашей интерпретации -- есть данные, есть plain old data контейнеры для них. А вот в ООСУБД все не так, там нет ни того, ни другого. Значит, с точки зрения anemic оно не может существовать. G>>>>Заметьте, я вообще ничего не говорил по этому поводу M>>>Вы говорили про "2 принципиально разные операции, Ничего другого придумать нельзя." выше. В ООСУБД этого нет, и не надо. Надо же, придумали G>>Ну, ссылку на такую ООСУБД в студию. Естественно она должна быть многопользовательской и поддерживать ACID трензакции. M>Db4o в режиме "remote server"
А чего в нем особенного, я тоже самое могу написать на MS SQL + EF, отличия чисто синтаксически будут. Единственное что схему заранее создават не надо, хотя если типы объектов известны на этапе компиляции, то разницы нет. Более того, для реляционной БД я могу еще проекциии, группировки и соединения делать. Что в этом плане db4o предложить может?
M>>>>>Бгг, это вы мне будете говорить, есть там или нет? Мой domain, помещаю, что хочу. У меня -- есть. G>>>>Только domain expert вас не поймет. Да и нету в предметной области report calculator, ни в какой. G>>>>Или будет контрпример? M>>>Только что был, с report calculator. В реальном проекте ситуация не сильно отличается, только там не report, а statistics. G>>И какой части предметной области он соответсвует? M>Вам в каких единицах отмерять? Видимо, я не понял вопроса.
Какому объекту предметной области соовествует report calculator или statistics? А состояние у этого объекта какое? Какими либо персистными даннми н заведует? как domain expert понимает что это за объект?
M>>>>>Однако, в моей ситуации ~85-95% данных оказываются в объектном кеше (это цифры из реальной программы). Readonly справочники туда ложатся сразу после прогрева кеша. При этом я не написал для этого ни строки -- все делает инфраструктура (NHibernate + Spring.net) G>>>>Наличие объектного кеша большой костыль. M>>>Ваше мнение. Пруфлинк, или неправда. G>>Пруф заключается в том, что есть системы которым не нужнен огромный кеш для нормально работы. M>Отличный пруф, продолжайте дальше. Есть системы, которым и БД не нужна. Про "огромный кеш" еще можно поспорить.
Ну если БД не нужна, то и обсуждать тут нечего. А когда БД нужна далеко не всегда такой кеш нужен.
M>>>>>Опять 25 ) Не буду пересказывать Фаулера, потому что не хочу опять обсуждать мое понимание его письмен ) G>>>>Не надо фаулера пересказываеть, его тут все читали. Свое мнение, основанное не на утверждении что это "больше ООП". M>>>Вкратце, чистота domain logic, код ближе к данным, с которыми он работает; далее, мне так привычнее ) G>>Ключевое выделил. G>>domain logic чистотой не обладает, так как задейтсован LL, который может давать эффекты сказывающиеся на производительности. G>>Код ближе к данным — вероятнее всего нарушение SRP. M>Ваше мнение. Тогда и ООП -- нарушение SRP из ООП.
Читайте что такое SRP. Определение очень простое.
G>>>>А я видел, и использую. и мне для этого не надо использовать memcached на 4 машинах. M>>>Не придирайтесь. Пример с кешем из реального проекта иллюстрировал то, что "на каждый чих ходить в БД" -- это неверное представление о ситуации. G>>Ну можно ходить в распределенный кеш. Который тоже является своего рода СУБД, только гораздо более слабой. G>>Единственное его преимущество, то что он быстрый "снаружи". M>Я и иллюстрировал вам распределенный кеш. Преимущество -- что не загибается БД на выборках, а сами выборки -- в 10-100 раз быстрее
На тему оптимизации можно разговаривать отдельно и долго.
Но кажется синклер тут приводил факты что при нормальном проектировании одна БД способна закормить от 2 до 10 приложений. если у вас БД загибается и вам нужен распределенный кеш только для того чтобы все работало с приемлимой скоростью это уже свидетельстует о неоптимальности работы с базой.
Кстати, склько у вас выборок (если профайлером посмотреть) нестатичных данных случается при обработке одного запроса пользователя?
Сколько при этом явных запросов на получение данных?
G>>Не надо в теории доказывать, приведите пример, причет полный, без сокрытия самых интересных частей. M>Хорошо, несколько позже приведу.
ОК.
Re[26]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, Mike Chaliy, Вы писали:
MC>Здравствуйте, meowth, Вы писали:
M>>>>Пример из жизни: однажды у нас пропало соединение с БД. Логика еще минут 30-40 работала из кеша. В проектируемой системе сейчас 8G memcached на 4х машинах, занятые обычно процентов на 15-40. G>>> G>>>Скока скока? Гиг-два в кеше? А размер базы какой? G>>>Я-то по наивности делаю так чтобы на shared-хостинге решение развернуть можно было. M>>Размер базы 50G. А вы много чего делаете по наивности; например, паясничаете строкой выше.
MC>ИМХО этим все сказано, кто-то делает сайты для е-комерс, по три десятка на неделю. А кто-то таки делает корпоративный приложения. У нас опции шаред хостинга даже в теории нема. Наивно предполагать что человек педалящий первое может чему-то научить человека педалящего второе.
Я делал и первое и второе. Разница по сути небольшая.
В enterprise даже проще, там люди готовы терпеть тормозняки, а в вебе за каждую миллисекунду борьба, ибо мало кто будет заходит на откровенно тормозной сайт, а отсутствие посетителей — убытки.
Re[28]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, gandjustas, Вы писали:
G>Все равно надо как-то объясниить инфраструктуре когда получать объекты и когда сохранять изменения.
Какая-то философия получается. Выпил, поговорил с инфраструктурой, объяснил, где получать объекты, как сохранять.
M>>Третье то, что коду бизнес-логики абсолюьно пофиг, что данные лежат где-то в БД. Их доставкой занимается инфраструктура и 1 (один сервис), называемый репозиторием. Причем это делается в режиме push, т.е. бизнес-логике вообще не надо никуда обращаться. G>Пример кода в студию. Даже интересно как такое выгялдит.
Будет вам код, будет
G>А причем тут repository? Вот есть у нас объекта заказа. У него очевидно нету поведения.
Не передергивайте. Ваши "очевидно" очевидны только вам, видимо, даже с контрпримерами. G>Кто будет заниматтся созданием заказа?
Зависит от конкретного приложения; скорее всего, ordering facade.
G>>>Доказательством является саом наличие persistance инфрастуктуры с Identity map, Unit of work и прочими паттернами. M>>Не спорю. Но я не хочу работать с ними как с plain data, поэтому и есть эта инфраструктура. G>Инфраструктура пытается скрыть факт, что это данные, а не объекты. Причем очень несупешно. Особенно это заметно при множестве параллельных операций.
Покажите, как это заметно.
G>>>Пока еще никому не удалось изобрести БД, которая отдает объекты (имеенно объекты, а не копию данных) с ссылочной эквивалентностью и без необходмости дополнительного преобразование, и чтобы при этом не было необходимости явно сохранять изменения. M>>В Smalltalk загляните -- там это есть. G>Ссылку?
Легко. Самое доступное изложение -- тут. Прочтите про squeak. http://habrahabr.ru/blogs/programming/55797/
G>Ну как работает приведите пример требований и решение с помощью DDD. G>А потом разберем посмотрим как оно будет в anemic и ответим на несколкьо "что если", чтобы оценить расширяемостиь решения.
Предлагаю начать вам -- чтобы я мог ориентироваться по требованиям. А то потом опять будет -- то report calculator в domain не может быть, то кэш слишком большой и не устраивает.
M>>>>Вы говорили про "2 принципиально разные операции, Ничего другого придумать нельзя." выше. В ООСУБД этого нет, и не надо. Надо же, придумали G>>>Ну, ссылку на такую ООСУБД в студию. Естественно она должна быть многопользовательской и поддерживать ACID трензакции. M>>Db4o в режиме "remote server" G>А чего в нем особенного, я тоже самое могу написать на MS SQL + EF, отличия чисто синтаксически будут. G>Единственное что схему заранее создават не надо, хотя если типы объектов известны на этапе компиляции, то разницы нет. Более того, для реляционной БД я могу еще проекциии, группировки и соединения делать. Что в этом плане db4o предложить может?
Особенности db4o и то, что она может предложить, следует обсуждать в отдельном топике. Не уводите тему разговора. Вы просили ссылку, я привел, вы с ней согласились. То, что вы такое тоже можете реализовать (медаль вам, ту самую, кстате ) -- это оффтоп. Оффтоп -- в оффтопку.
G>Какому объекту предметной области соовествует report calculator или statistics? А состояние у этого объекта какое? Какими либо персистными даннми н заведует? как domain expert понимает что это за объект?
Никакому, я же сказал -- это синтетический объект, который введен, чтобы процесс построения отчета был более доступен для понимания. Он заведует данными о статистике обращений в БД по некоторому профилю. Что-то типа Builder в GoF. Так как статистика строится за период наблюдения, он представляет эти данные -- историю выборок.
G>>>Пруф заключается в том, что есть системы которым не нужнен огромный кеш для нормально работы. M>>Отличный пруф, продолжайте дальше. Есть системы, которым и БД не нужна. Про "огромный кеш" еще можно поспорить. G>Ну если БД не нужна, то и обсуждать тут нечего. А когда БД нужна далеко не всегда такой кеш нужен.
Если лично вы против объектного кеша, то это ваши проблемы. Если одно его наличие так сильно отвращает вас от rich, то имхо у вас трудности, с которыми, боюсь, я не смогу помочь.
G>На тему оптимизации можно разговаривать отдельно и долго. G>Но кажется синклер тут приводил факты что при нормальном проектировании одна БД способна закормить от 2 до 10 приложений. если у вас БД загибается и вам нужен распределенный кеш только для того чтобы все работало с приемлимой скоростью это уже свидетельстует о неоптимальности работы с базой. G>Кстати, склько у вас выборок (если профайлером посмотреть) нестатичных данных случается при обработке одного запроса пользователя? G>Сколько при этом явных запросов на получение данных?
При чем здесь оптимизация? Объектный кеш -- это, как и identity map, enabling tool для rich-модели.
_распределенный_ кеш мне нужен для того, чтобы а)работало в кластере б)перезапуск приложения на одном из узлов проходил гладко, без тормозов, связанных с dog-pile эффектом
Количество обращений зависит от характера запроса. Если вы имеете в виду SQL-профайлер, то в среднем — от 2х (выборка для механизма безопасности) до 6-8. Это порядка 70%-90% от всех запросов при нормальной работе пользователей.
По-моему, вы пытаетесь придраться к кешу. Перестаньте уже, не о том разговор.
G>>>Не надо в теории доказывать, приведите пример, причет полный, без сокрытия самых интересных частей. M>>Хорошо, несколько позже приведу. G>ОК.
Я чуть выше написал, что хотел бы получить от вас вводную в виде anemic перед тем, как написать свой вариант.
Re[29]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, Ocenochka, Вы писали:
G>>Читайте что такое SRP. Определение очень простое.
O> Хочу знать, что такое SRP и PI тут упоминаемые. O> Нагуглить удалось только ваш blog(spot) и в нем определений нет.
Здравствуйте, Ocenochka, Вы писали:
O> Хочу знать, что такое SRP и PI тут упоминаемые. O> Нагуглить удалось только ваш blog(spot) и в нем определений нет.
Не знаю, как вы гуглите, но по запросу SRP в гугле — первая же ссылка — http://en.wikipedia.org/wiki/Single_responsibility_principle
С PI в гугле посложнее, но в общем это Persistence Ignorance, подход при котором слой бизнес логики и модель предметной области не знают ничего о том где и в каком виде данные сохраняются, читаются и как это происходит. Т.е. из бизнес логики исключается код, отвечающий за непосредственное сохранение/чтение данных и все нюансы с этим связанные.
Persistence Ignorance подход способствует:
1) вышеупомянутому SRP
2) снижению coupling (все время забываю как лучше на русский перевести и чтобы никто не перепутал с cohesion)
3) упрощению тестирования кода (улучшению тестируемости)
4) повторному использованию
5) лучшему структурированию и разделению кода по функциональности (separation of concerns, что в общем-то тоже можно отнести к SRP)
А вот _вы_ -- радикально отказываетесь от логики в объектах ) В этом -- наша сила.
