Здравствуйте, Enomay, Вы писали:
G>>И это будет максимально эффективным решением.
E>ровно до тех пор, пока это будет оставаться небольшим интернет-магазином.
I>>Смотри свои высказывания: I>>1 "ddd — это не только принцип, но и архитектура с определенным разбиением ..." I>>2 "примеры, которые он приводит, демонстрируют его мнение о ddd как архитектуре, а там — именно рич-модель" I>>3 "Если в качестве первоисточника обращаться к эвансу, то ddd — это все-таки рич."
I>>Эванс пишет чуток другое
I>>1 ДДД это принцип, который можно применить к разным архитектурам L>Кэп?
"ddd — это все-таки рич" и "ddd — это разные архитектуры"
I>>2 примеры приведены только для самой популярной модели L>Это несомненно делает их не рич, не так ли?
Ты же про его мнение пишешь, а не про примеры.
I>>3 в книге про ДДД, примеры — рич, но из этого никак не следует, что ДДД это рич.
L>Да, не следует. Сколько раз мне с этим нужно согласиться, чтобы ты перестал это повторять?
Ты не только соглашаешься но и продолжаешь утверждать прямо противоположные вещи
L>>>Я же написал, что "Архитектура ДДД по Эвансу — рич", что означет то, и только то, что там написано: есть архитектура ДДД по Эвансу (честно-честно есть, смотрите главы 4-7) и она — рич. Точка.
I>>То есть, ты хотел сказать, что ДДД по Эвансу это ДДД по Эвансу ? Спасибо, Капитан
L>Нет, я хотел сказать (и сказал), что "архитектура ДДД по Эвансу — рич". Но до тебя все никак не дойдет.
Ты за столько сообщений так и не пояснил, что же ты хотел этим сказать. Что примеры там рич ?
I>>То есть ты уверен, что всегда есть возможность написать один запрос который получает все данные ? G>Да, причем это математически доказано.
иногда эти запросы становятся огромными, сложными, и не эффективными, что даже у сиквела срывает крышу, и порой проще сделать 3 запроса более точечных и простых, нежели 1 тяжелый.
I>>Какой бы инструмент ты не выбрал, там будет тоже самое — слишком большой объём выборки для вычисления определенной функции. G>Фигня, SQL Server сам такие вычисления легко делает, он для этого и проектировался.
SQL Server у нас ложился про подсчете уникальных посетителей сайта. а это очень простая операция.
так что, как показывает практика, не так уж легко он делает вычисления.
Здравствуйте, gandjustas, Вы писали:
I>>То есть ты уверен, что всегда есть возможность написать один запрос который получает все данные ? G>Да, причем это математически доказано.
Неужели математической доказательство может отметить сложности технической реализации ? Каюсь, не знал. Я то думал на каждую операцию надо время, хотя бы и маленькое, а оказывается математика может _любую_ операцию сделать равной нулю по затратам времени. Не подскажешь, почему эта математика не может сделать так, что бы твой комп хотя бы загружался или просыпался за ровно 0 секунд ?
I>>Я немного не точно выразился, selеct n+1 это проблема реализации, но это пробема вторичная, реальная причина в самой предметной области, т.е. в той задаче которую хочет решить заказчик — слишком большой объём выборки для вычисления определенной функции. Слишкой большой это относительно возможностей современных технологий. G>Ни разу он не большой.
Это в твоих задачах объёмы небольшие.
I>>Какой бы инструмент ты не выбрал, там будет тоже самое — слишком большой объём выборки для вычисления определенной функции. G>Фигня, SQL Server сам такие вычисления легко делает, он для этого и проектировался.
Какие такие ? Ты уверен, что за 0.5с для реакции на мышиный клик, твой SQL Server подтянет любое необходимое количество инфы, которую нужно будет еще процессить дополнительно ? Чудеса, ты нашел сервер с бесконечно высокой скоростью, ну ка, поделись этой пулькой
Я вот точно знаю, что для многих задач даже секунд будет недостаточно даже для того, что бы только подтянуть инфу, а у тебя какое то чудо выходит
I>>Все что я хотел сказать, я уже сказал : "Пожелания нужно рассматривать и анализировать,а учитывать или нет — это решает маркетинг" G>Ну ты просто пытаешься с себя снять ответственность за некоторый класс ошибок — неблагородно.
Наоборот, я говорю о том, что часть пожеланий никогда не будет учтена и это осознанный выбор. Например если часть пользователей будет ныть и требовать что бы сайт работал под ихним древним железом P-100 + ИЕ4 Win-98, то маркетинг смело посылает таких пользователей нахрен.
I>>Хочешь опровергнуть это, покажи пример грузового-легкового минивена-родстера G>А зачем такая машина нужна? Лучше иметь несколько разных машин.
Автомобилисты как правило достаточно грамотные относительно пользователей софта, тем не менее и там встречается целая куча пожеланий, которые никто никогда в своём уме не будет учитывать.
G>>>Вполне может быть что это так, вот только об этом никто не говорит. Или у тебя есть ссылки на подобные высказывания со стороны апологетов DDD? I>>Об этом говорит сам Эванс и этого достаточно G>Ну, ссылку, цитату. Я видел обратное.
Здравствуйте, Ikemefula, Вы писали:
I>>>Эванс пишет чуток другое
I>>>1 ДДД это принцип, который можно применить к разным архитектурам L>>Кэп?
I>"ddd — это все-таки рич" и "ddd — это разные архитектуры"
А ты не вырывай из контекста.
I>>>2 примеры приведены только для самой популярной модели L>>Это несомненно делает их не рич, не так ли?
I>Ты же про его мнение пишешь, а не про примеры.
Я не знаю его мнения, я знаю только то, что написано в книге. А там описана вполне определенная архитектура.
I>>>3 в книге про ДДД, примеры — рич, но из этого никак не следует, что ДДД это рич.
L>>Да, не следует. Сколько раз мне с этим нужно согласиться, чтобы ты перестал это повторять?
I>Ты не только соглашаешься но и продолжаешь утверждать прямо противоположные вещи
Ты просто постарайся не вырывать куски и тогда никаких противоположных вещей не будет. Это просто, главное начать.
L>>>>Я же написал, что "Архитектура ДДД по Эвансу — рич", что означет то, и только то, что там написано: есть архитектура ДДД по Эвансу (честно-честно есть, смотрите главы 4-7) и она — рич. Точка.
I>>>То есть, ты хотел сказать, что ДДД по Эвансу это ДДД по Эвансу ? Спасибо, Капитан
L>>Нет, я хотел сказать (и сказал), что "архитектура ДДД по Эвансу — рич". Но до тебя все никак не дойдет.
I>Ты за столько сообщений так и не пояснил, что же ты хотел этим сказать. Что примеры там рич ?
Здравствуйте, Enomay, Вы писали:
E> эта методология, как и всё остальное, не является серебряной пулей, и не может решать всех задач.
Вот это пожалуй единственная здравая мысль за всю дискуссию. Осталось сделать небольшой шажок и понять — для каких именно задач DDD более-менее подходит. hint: класс этих задач весьма ограничен.
E>преимущество применения DDD методологии в более красивом и структурированном объектно-ориентированном коде, который собой отражает проблему и её решение. E>это же очевидно.
Вы тут уже съехали с ООП головного мозга на полный DDD головного мозга. К сожалению это почти не лечится. )
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>То есть ты уверен, что всегда есть возможность написать один запрос который получает все данные ? G>>Да, причем это математически доказано.
I>Неужели математической доказательство может отметить сложности технической реализации ?
Разве это отменяет возможность?
I>Каюсь, не знал. Я то думал на каждую операцию надо время, хотя бы и маленькое, а оказывается математика может _любую_ операцию сделать равной нулю по затратам времени. Не подскажешь, почему эта математика не может сделать так, что бы твой комп хотя бы загружался или просыпался за ровно 0 секунд ?
А ты считаешь что другие способы обработки большого объема данных будут быстрее? Написать sum в запросе гораздо проще, чем циклы и if_ы которые суммируют числа.
I>>>Я немного не точно выразился, selеct n+1 это проблема реализации, но это пробема вторичная, реальная причина в самой предметной области, т.е. в той задаче которую хочет решить заказчик — слишком большой объём выборки для вычисления определенной функции. Слишкой большой это относительно возможностей современных технологий. G>>Ни разу он не большой. I>Это в твоих задачах объёмы небольшие.
Какая разница? Это отменяет тот факт что select n+1 — проблема реализации?
I>>>Какой бы инструмент ты не выбрал, там будет тоже самое — слишком большой объём выборки для вычисления определенной функции. G>>Фигня, SQL Server сам такие вычисления легко делает, он для этого и проектировался.
I>Какие такие ? Ты уверен, что за 0.5с для реакции на мышиный клик, твой SQL Server подтянет любое необходимое количество инфы, которую нужно будет еще процессить дополнительно ? Чудеса, ты нашел сервер с бесконечно высокой скоростью, ну ка, поделись этой пулькой I>Я вот точно знаю, что для многих задач даже секунд будет недостаточно даже для того, что бы только подтянуть инфу, а у тебя какое то чудо выходит
Конечно получить список заказов для кастомера за последний месяц и всех его позиций с суммированием по цене SQL Server сделает достаточно быстро, чтобы уложиться в 0.5 сек. Главное сделать индексы правильные.
I>>>Все что я хотел сказать, я уже сказал : "Пожелания нужно рассматривать и анализировать,а учитывать или нет — это решает маркетинг" G>>Ну ты просто пытаешься с себя снять ответственность за некоторый класс ошибок — неблагородно.
I>Наоборот, я говорю о том, что часть пожеланий никогда не будет учтена и это осознанный выбор. Например если часть пользователей будет ныть и требовать что бы сайт работал под ихним древним железом P-100 + ИЕ4 Win-98, то маркетинг смело посылает таких пользователей нахрен.
Нет, в выделенном ты сказал то что не ты отвечаешь за функционал и снял с себя ответственность за это. Что ты имел ввиду мне неинтересно.
G>>>>Вполне может быть что это так, вот только об этом никто не говорит. Или у тебя есть ссылки на подобные высказывания со стороны апологетов DDD? I>>>Об этом говорит сам Эванс и этого достаточно G>>Ну, ссылку, цитату. Я видел обратное.
I>См. пример про смешение цветов.
Здравствуйте, Enomay, Вы писали:
I>>>То есть ты уверен, что всегда есть возможность написать один запрос который получает все данные ? G>>Да, причем это математически доказано.
E>иногда эти запросы становятся огромными, сложными, и не эффективными, что даже у сиквела срывает крышу, и порой проще сделать 3 запроса более точечных и простых, нежели 1 тяжелый.
Ну так делай.
I>>>Какой бы инструмент ты не выбрал, там будет тоже самое — слишком большой объём выборки для вычисления определенной функции. G>>Фигня, SQL Server сам такие вычисления легко делает, он для этого и проектировался.
E>SQL Server у нас ложился про подсчете уникальных посетителей сайта. а это очень простая операция. E>так что, как показывает практика, не так уж легко он делает вычисления.
Ты бы хоть понимал что пишешь...
Подсчет уникальных значений делается при помощи сортировки исходного набора данных, которая n*log(n) как минимум и удаления дубликатов. так что это ни разу не простая операция, несмотря на то что тебе так кажется.
Если сделать индекс по значению, которое должно быть уникальным, то сэкономишь на на сортировке, но все равно потребуется вытянуть все строкни с диска чтобы удалить дубликаты.
А если ты сделаешь таблицу, куда всех пользователей записывать по одному разу, и на нее ссылаться из таблицы визитов, то подсчет количества можно сделать индексом, в идеале индексированным представлением.
E>>SQL Server у нас ложился про подсчете уникальных посетителей сайта. а это очень простая операция. E>>так что, как показывает практика, не так уж легко он делает вычисления.
G>
G>Ты бы хоть понимал что пишешь... G>Подсчет уникальных значений делается при помощи сортировки исходного набора данных, которая n*log(n) как минимум и удаления дубликатов. так что это ни разу не простая операция, несмотря на то что тебе так кажется.
G>Если сделать индекс по значению, которое должно быть уникальным, то сэкономишь на на сортировке, но все равно потребуется вытянуть все строкни с диска чтобы удалить дубликаты.
G>А если ты сделаешь таблицу, куда всех пользователей записывать по одному разу, и на нее ссылаться из таблицы визитов, то подсчет количества можно сделать индексом, в идеале индексированным представлением.
когда у тебя будут такие объемы, будешь рассказывать как нужно делать. а пока у тебя интернет магазинчик, твоё мнение ниразу не интересно.
а то оно конечно классно рассуждать. индексов напихать, а потом выгребать на вставке, с учетом того, что у нас пишется около 20к записей в секунду
Здравствуйте, Enomay, Вы писали:
G>>Хранить ты его не можешь, как как нужна сумма за месяц с текущего момента. E>в сиквеле, нет, в документной базе, без проблем в общем-то.
Каким образом? Покажи как по изменяющемуся критерию хранить значение?
G>>>>Какая-то фейерическая глупость чтобы оправдать проблемы.
E>>>какие проблемы? у меня нет проблем. для меня DDD вполне эффективная методология. G>>В чем её эффективность? Есть выражение этой эффективности в цифрах? Я пока вижу проблемы с быстродейтсвием. E>это от того, что ты не понимаешь как это можно применять. E>на деле же, это можно развернуть как в масштабируемое приложение, так и пожертвовать быстродействием, если оно нас не волнует.
За счет чего? Что ты в DDD масштабировать будешь?
E>>>для тебя нет. но ты пытаешься, пыжишься. для чего только, не ясно. G>>Эффективность или есть или её нет, не бывает что для кого-то она есть, а для другого нет.
E>человек умеет работать каким-то инструментом. E>есть другой инструмент, более высокотехнологический, который позволяет повысить эффективность в 2 раза. E>но человек не умеет им пользоваться, и получает производительность в 2 раза ниже, от производительности своего более простого инструмента. E>ясно?
Человек может научиться, а могие чем больше узнают DDD, тем больше понимают его неэффективность. Какая обратная зависимость в отличие от "инструмента".
G>>То есть ты не знаешь в чем заключается методология DDD? E>ты волен считать так, как тебе больше нравится
Ты скажи. Мне интересно твое мнение, а то ты говоришь "методология DDD", но не можешь её описать.
G>>>>Каким образом? G>>>>Покажи его, чтобы оно было DDD и при этом достаточно эффективно. E>>>я уже приводил пару возможных примеров. G>>Оба гораздо менее эффективны чем могли бы быть. E>они достаточно эффективны с точки зрения реализации бизнес логики. остальное — технические детали.
То есть тормозное говно, и ты с этим согласен.
G>>Я не про масштабирование ресурсов, я про масштабрирование задачи. SOA-подход работает как на простой задаче, выполняющийся на одной машине, так и в сильно распределенной среде. В отличие от ООП. Объекты распределять крайне неэффективно. E>объекты распределять и не требуется.
А что будет распределяться?
E>более того, в реализацию SOA вполне может лечь ООП. а это значит, что там может быть использован DDD.
Не может, ООП как подход проектированию не совместим с SOA, а вот сделать сервисы SOA из классов, вполне может быть, только не ООП это.
И где там может быть использован DDD? Покажешь пример?
G>>В среднем anemic кода получается меньше, чем rich при той же задаче. О какой простоте поддержки ты говоришь? E>а говорил строками код не меряешь. E>но меньше кода, не значит лучше.
Да, лучше больше функционала, вот anemic и позволяет получить больше функционала за меньше строк (почему-то сходу написал "денег").
А что для тебя "лучше"?
E>>>ты опять говоришь глупости и перевираешь мои слова. перечитай еще раз про дистилляцию. G>>Читал, и что? Дистиллируй сколько хочешь, но если эксперт говорит что-то, то это надо или учитывать в модели или переучивать эксперта. E>я уже давно понял почему DDD методология для тебя не эффективна, но ты в очередной раз доказываешь мою правоту.
Каждый человек по-своему прав, и ты тоже. По-настоящему он прав, когда другие соглашаются. Ты неправ
G>>Думаешь если не слушать все вероятность ошибок уменьшится? Думаешь если ты при построении модели для бухгалтерии отбросишь обороты и потом совершенно случайно не сделаешь их, то пользователи останутся довольны? E>ты мешаешь всё подряд. у тебя каша в голове.
Это я пытаюсь из твоей каши хоть какую-то информацию достать, а то ты вещаешь лозунги с первой страницы domaindrivendesign.org и других сайентологов, не особо вникая о чем они.
E>>>у тебя получится anemic, у меня будет домен. G>>Приведи пример, посмотрим. E>ты слишком много хочешь. E>примеров, полный гугл.
Дай ссылку чтоли.
E>>>это в данном случае не важно. мы можем передать признак, можем передать число, равняющееся сумме предыдущих покупок, на основании которого будем делать скидку. G>>Это как раз важно, откуда мы передадим это число? E>ты в 10 раз задаешь один и тот же вопрос. перечитай тред, ответ там есть.
да, ответ там есть: мы число получим в сервисе, а потом передадим в объект, это менее эффективно чем считать скидку в сервисе. Ведь можно получить ту же скидку, не материализуя объект. ты не согласен и сам продолжаешь ходить по-кругу, пытаясь найти преимущества материализации объектов.
Вот только нет этих преимуществ.
E>>>проще говоря, добавь покупателю поле с суммой покупок, и получай её сразу с покупателем. G>>Нельзя, потому что требуется сумма покупок за последний месяц, то есть вычисление на момент покупки, хранить значение ты не сможешь. E>смогу.
Ок, покажи как.
E>>>хуже для тебя. потому что процедурный стиль программирования тебе ближе. E>>>в целом же, с точки зрения ООП, это правильная реализация. а DDD как раз более чем придерживается ООП парадигмы. G>>То есть единственная цель "придерживаться ООП парадигмы" чего бы оно не стоило? E>цель — использовать преимущества ООП парадигмы при решении задач. а так же DDD методологии. E>но для кого-то функциональное программирование кажется лучшим решением. это его право. и это 2 совершенно разных подхода.
Какие это преимущества, ты так и не ответил. У тебя получается преимущество ООП в использовании ООП. Остальное только недостатки.
E>>>верно и обратное, что в DDD не всегда и всё необходимо материализовывать. при необходимости, мы без проблем можем вызвать сервис, который сделает update с условием. G>>Да, и это уже будет anemic, потому что есть сервис и нет "доменных объектов". E>ошибаешься, доменные объекты есть. именно они и решают где и какой update сделать.
Каким образом решают? Пример кода приведешь?
E>>>насчет размазывания логики по нескольки объектам, ну так это ж банальный принцип "ответственности" из SOLID, да и ООП в целом. так что это правильная реализация. G>>В SOLID куча других принципов, да и за пределами SOLID тоже, и DDD, как его описывает эванс, многое нарушает.
E>нет, DDD это классическое ООП, и ничего не нарушает.
Само по себе конечно не нарушает. Но если следовать фаулеру, то нарушает. Domain Model нарушает SRP как минимум.А если выносить из доменных объектов всю логику в "доменные сервисы", то нарушает принцип бритвы оккама.
E>а вот anemic, в общем-то, не является ООП подходом.
Почему не является? Там есть классы, есть поведение, инкапсулированное в классах, там есть полиморфизм, основанный на реализации интерфейсов. Вот и докажи что ООП нет? Может быть там нет ОО-дизайна, описанного Бучем и Мейером, так уже давно известно что они довольно плохой дизайн описали по куче формальных признаков.
E>разные реализации. ты используешь процедурный подход, мы ООП.
От повторения это правдой не станет.
E>в корпоративном секторе ни процедурного, ни функционального подхода для реализации БЛ нет. что очевидно.
Не очевидно, докажи.
Здравствуйте, Enomay, Вы писали:
E>>>SQL Server у нас ложился про подсчете уникальных посетителей сайта. а это очень простая операция. E>>>так что, как показывает практика, не так уж легко он делает вычисления.
G>>
G>>Ты бы хоть понимал что пишешь... G>>Подсчет уникальных значений делается при помощи сортировки исходного набора данных, которая n*log(n) как минимум и удаления дубликатов. так что это ни разу не простая операция, несмотря на то что тебе так кажется.
G>>Если сделать индекс по значению, которое должно быть уникальным, то сэкономишь на на сортировке, но все равно потребуется вытянуть все строкни с диска чтобы удалить дубликаты.
G>>А если ты сделаешь таблицу, куда всех пользователей записывать по одному разу, и на нее ссылаться из таблицы визитов, то подсчет количества можно сделать индексом, в идеале индексированным представлением.
E>когда у тебя будут такие объемы, будешь рассказывать как нужно делать. а пока у тебя интернет магазинчик, твоё мнение ниразу не интересно.
У меня нет инетрнет-магазина, к сожалению, хотя я их немало сделал.
E>а то оно конечно классно рассуждать. индексов напихать, а потом выгребать на вставке, с учетом того, что у нас пишется около 20к записей в секунду
На 20к в секунду от записи база ляжет в первую очередь. Тогда просто подключайте OLAP и будет счастье.
G>>>Хранить ты его не можешь, как как нужна сумма за месяц с текущего момента. E>>в сиквеле, нет, в документной базе, без проблем в общем-то. G>Каким образом? Покажи как по изменяющемуся критерию хранить значение?
для этого есть доменная модель, которая этим занимается.
у тебя проблемы с проектированием такой вещи?
E>>это от того, что ты не понимаешь как это можно применять. E>>на деле же, это можно развернуть как в масштабируемое приложение, так и пожертвовать быстродействием, если оно нас не волнует. G>За счет чего? Что ты в DDD масштабировать будешь?
о CQRS слышал? одни из наиболее эффективных систем для высоконагруженных решений с достаточно хорошим масштабированием, применяемая в большом кол-ве проектов. и о ужас! в основе её лежит доменная модель!!!
но раз ты сказал что DDD говно, они обязательно все перепишут.
G>Человек может научиться, а могие чем больше узнают DDD, тем больше понимают его неэффективность. Какая обратная зависимость в отличие от "инструмента".
человек, если у него руки не из того места, может и не научится.
касательно многих, то 95% людей идиоты. и если они не понимают преимущества DDD, то это не делает саму методологию хуже, но определенным образом характеризует людей.
G>>>То есть ты не знаешь в чем заключается методология DDD? E>>ты волен считать так, как тебе больше нравится G>Ты скажи. Мне интересно твое мнение, а то ты говоришь "методология DDD", но не можешь её описать.
своё мнение я сделал сам. и оно меня вполне устраивает.
рекомендую тебе заняться тем же самым.
E>>они достаточно эффективны с точки зрения реализации бизнес логики. остальное — технические детали. G> G>То есть тормозное говно, и ты с этим согласен.
ты читаешь между строк, и видишь только то, что хочешь видеть.
но пусть будет так. если тебя это радует
G>>>Я не про масштабирование ресурсов, я про масштабрирование задачи. SOA-подход работает как на простой задаче, выполняющийся на одной машине, так и в сильно распределенной среде. В отличие от ООП. Объекты распределять крайне неэффективно. E>>объекты распределять и не требуется. G>А что будет распределяться?
в интернете этого добра хватает. вон Грег Янг ездит с докладами по миру. сходи, послушай.
E>>более того, в реализацию SOA вполне может лечь ООП. а это значит, что там может быть использован DDD. G>Не может, ООП как подход проектированию не совместим с SOA, а вот сделать сервисы SOA из классов, вполне может быть, только не ООП это. G>И где там может быть использован DDD? Покажешь пример?
опять какие-то глупости пошли.
в основе сервисов лежит DDD. это даже у Эванса есть.
а иначе что делает сервис? тупо возвращает данные?
возможно. в таком случае домен может быть на другой стороне этой цепочки.
G>>>В среднем anemic кода получается меньше, чем rich при той же задаче. О какой простоте поддержки ты говоришь? E>>а говорил строками код не меряешь. E>>но меньше кода, не значит лучше. G>Да, лучше больше функционала, вот anemic и позволяет получить больше функционала за меньше строк (почему-то сходу написал "денег"). G>А что для тебя "лучше"?
без проблем. используй анемик. разве тебя кто-то заставляет писать по другому?
тебя даже никто не пытается переубедить.
G>>>Думаешь если не слушать все вероятность ошибок уменьшится? Думаешь если ты при построении модели для бухгалтерии отбросишь обороты и потом совершенно случайно не сделаешь их, то пользователи останутся довольны? E>>ты мешаешь всё подряд. у тебя каша в голове. G>Это я пытаюсь из твоей каши хоть какую-то информацию достать, а то ты вещаешь лозунги с первой страницы domaindrivendesign.org и других сайентологов, не особо вникая о чем они.
я просто троллю. а ты пыжишься чего-то.
E>>>>у тебя получится anemic, у меня будет домен. G>>>Приведи пример, посмотрим. E>>ты слишком много хочешь. E>>примеров, полный гугл. G>Дай ссылку чтоли.
забанили в гугле?
E>>>>это в данном случае не важно. мы можем передать признак, можем передать число, равняющееся сумме предыдущих покупок, на основании которого будем делать скидку. G>>>Это как раз важно, откуда мы передадим это число? E>>ты в 10 раз задаешь один и тот же вопрос. перечитай тред, ответ там есть. G>да, ответ там есть: мы число получим в сервисе, а потом передадим в объект, это менее эффективно чем считать скидку в сервисе. Ведь можно получить ту же скидку, не материализуя объект. ты не согласен и сам продолжаешь ходить по-кругу, пытаясь найти преимущества материализации объектов. G>Вот только нет этих преимуществ.
реализация логики в сервисе, это конечно можно. для процедурного программирования. но ООП как бы говорит о другом. и я придерживаюсь последнего подхода, в отличии от тебя.
эффективности при решении задач оно не убавляет. для больших проектов выгода очевидна.
и опять ты кидаешься в крайности. для тебя если DDD, то материализовать всё. но это не так.
E>>>>проще говоря, добавь покупателю поле с суммой покупок, и получай её сразу с покупателем. G>>>Нельзя, потому что требуется сумма покупок за последний месяц, то есть вычисление на момент покупки, хранить значение ты не сможешь. E>>смогу. G>Ок, покажи как.
ты и такую задачу реализовать не можешь?
E>>цель — использовать преимущества ООП парадигмы при решении задач. а так же DDD методологии. E>>но для кого-то функциональное программирование кажется лучшим решением. это его право. и это 2 совершенно разных подхода. G>Какие это преимущества, ты так и не ответил. У тебя получается преимущество ООП в использовании ООП. Остальное только недостатки.
о преимуществах написано в соответствующих книгах. я не собираюсь дублировать тут написанное. достаточно прочесть, понять и применять. либо не понять, и распинаться на форуме о том, какое это говно.
правда хуже оно от того не становится
E>>ошибаешься, доменные объекты есть. именно они и решают где и какой update сделать. G>Каким образом решают? Пример кода приведешь?
я кажется начинаю понимать. ты прочел Эванса, по диагонали, но как применять не понял. теперь от всех требуешь примеры кода. я угадал?
E>>нет, DDD это классическое ООП, и ничего не нарушает. G> G>Само по себе конечно не нарушает. Но если следовать фаулеру, то нарушает. Domain Model нарушает SRP как минимум.А если выносить из доменных объектов всю логику в "доменные сервисы", то нарушает принцип бритвы оккама.
опять глупости понеслись. Domain Model как раз очень четко вписывается в SRP, в отличии от твоих сервисов.
E>>а вот anemic, в общем-то, не является ООП подходом. G>Почему не является? Там есть классы, есть поведение, инкапсулированное в классах, там есть полиморфизм, основанный на реализации интерфейсов. Вот и докажи что ООП нет? Может быть там нет ОО-дизайна, описанного Бучем и Мейером, так уже давно известно что они довольно плохой дизайн описали по куче формальных признаков.
на самом деле наличие классов, наследование, полиморфизм и инкапсуляция, абсолютно не делают подход объектно ориентированным. у тебя класс это лишь объединение подобных по смыслу функций.
а вот поведения объектов у тебя нет.
только не нужно говорить про состояния, и в паскале были глобальные переменные.
но зато ты и сам подтвердил свою причину непонимания DDD — ты не знаешь что такое ООП и не умеешь его применять на практике. отсюда и процедурный подход, которым ты так гордишься.
E>>в корпоративном секторе ни процедурного, ни функционального подхода для реализации БЛ нет. что очевидно. G>Не очевидно, докажи.
если тебе это не очевидно, могу только по соболезновать.
E>>а то оно конечно классно рассуждать. индексов напихать, а потом выгребать на вставке, с учетом того, что у нас пишется около 20к записей в секунду G>На 20к в секунду от записи база ляжет в первую очередь.
конечно ляжет. потому у нас их кластер.
вот только тут твои методы и подходы уже перестают работать.
G>Тогда просто подключайте OLAP и будет счастье.
Здравствуйте, gandjustas, Вы писали:
I>>Неужели математической доказательство может отметить сложности технической реализации ? G>Разве это отменяет возможность?
Я то говорил про сложность
I>>Каюсь, не знал. Я то думал на каждую операцию надо время, хотя бы и маленькое, а оказывается математика может _любую_ операцию сделать равной нулю по затратам времени. Не подскажешь, почему эта математика не может сделать так, что бы твой комп хотя бы загружался или просыпался за ровно 0 секунд ? G>А ты считаешь что другие способы обработки большого объема данных будут быстрее? Написать sum в запросе гораздо проще, чем циклы и if_ы которые суммируют числа.
Ты еще 2+2 предложи в качестве примера Я считаю, что издержки select N+1 запросто могут быть наименьшими сравнивая с другими решениемя.
I>>>>Я немного не точно выразился, selеct n+1 это проблема реализации, но это пробема вторичная, реальная причина в самой предметной области, т.е. в той задаче которую хочет решить заказчик — слишком большой объём выборки для вычисления определенной функции. Слишкой большой это относительно возможностей современных технологий. G>>>Ни разу он не большой. I>>Это в твоих задачах объёмы небольшие. G>Какая разница? Это отменяет тот факт что select n+1 — проблема реализации?
Читай выделеное.
I>>Какие такие ? Ты уверен, что за 0.5с для реакции на мышиный клик, твой SQL Server подтянет любое необходимое количество инфы, которую нужно будет еще процессить дополнительно ? Чудеса, ты нашел сервер с бесконечно высокой скоростью, ну ка, поделись этой пулькой I>>Я вот точно знаю, что для многих задач даже секунд будет недостаточно даже для того, что бы только подтянуть инфу, а у тебя какое то чудо выходит G>Конечно получить список заказов для кастомера за последний месяц и всех его позиций с суммированием по цене SQL Server сделает достаточно быстро, чтобы уложиться в 0.5 сек. Главное сделать индексы правильные.
Я и говорю — это в твоих задачах надо мелочовку таскать вроде заказов за месяц.
I>>Наоборот, я говорю о том, что часть пожеланий никогда не будет учтена и это осознанный выбор. Например если часть пользователей будет ныть и требовать что бы сайт работал под ихним древним железом P-100 + ИЕ4 Win-98, то маркетинг смело посылает таких пользователей нахрен. G>Нет, в выделенном ты сказал то что не ты отвечаешь за функционал и снял с себя ответственность за это. Что ты имел ввиду мне неинтересно.
Наоборот, мы полностью берем ответсвенность на себя, когда даём отлуп определенным пользователям.
I>>См. пример про смешение цветов.
G>Скопируй сюда чтоли, у меня книги под рукой нет.
Здравствуйте, Enomay, Вы писали:
G>>>>Хранить ты его не можешь, как как нужна сумма за месяц с текущего момента. E>>>в сиквеле, нет, в документной базе, без проблем в общем-то. G>>Каким образом? Покажи как по изменяющемуся критерию хранить значение? E>для этого есть доменная модель, которая этим занимается. E>у тебя проблемы с проектированием такой вещи?
ну смотри, есть запрос вроде
select sum(ol.Price*ol.Quantity) as [Sum]
from Orders o
join OrderLines ol on o.Id = ol.OrderId
where ol.HasDiscount = 0 and o.CustomerId=@param
ando.Date>DATEADD(m,-1,GETDATE())
Как ты такое будешь хранить? Это надо вычислять.
E>>>это от того, что ты не понимаешь как это можно применять. E>>>на деле же, это можно развернуть как в масштабируемое приложение, так и пожертвовать быстродействием, если оно нас не волнует. G>>За счет чего? Что ты в DDD масштабировать будешь?
E>о CQRS слышал? одни из наиболее эффективных систем для высоконагруженных решений с достаточно хорошим масштабированием, применяемая в большом кол-ве проектов.
Конечно и ничего нового в этой аббривеатуре нет, очереди + воркеры.
E>и о ужас! в основе её лежит доменная модель!!!
не-а, в её основе лежать очереди и воркеры, а доступ к данным может быть абсолютно любым.
E>но раз ты сказал что DDD говно, они обязательно все перепишут.
Нет, переписывать — экономически неэффективное занятие почти всегда.
G>>Человек может научиться, а могие чем больше узнают DDD, тем больше понимают его неэффективность. Какая обратная зависимость в отличие от "инструмента".
E>человек, если у него руки не из того места, может и не научится. E>касательно многих, то 95% людей идиоты. и если они не понимают преимущества DDD, то это не делает саму методологию хуже, но определенным образом характеризует людей.
Ага, прям как коммунизм
G>>>>То есть ты не знаешь в чем заключается методология DDD? E>>>ты волен считать так, как тебе больше нравится G>>Ты скажи. Мне интересно твое мнение, а то ты говоришь "методология DDD", но не можешь её описать.
E>своё мнение я сделал сам. и оно меня вполне устраивает. E>рекомендую тебе заняться тем же самым.
Так ты его озвучь, а то получается разговор с голосами в твоей голове, которые никто кроме тебя не слышит.
G>>>>Я не про масштабирование ресурсов, я про масштабрирование задачи. SOA-подход работает как на простой задаче, выполняющийся на одной машине, так и в сильно распределенной среде. В отличие от ООП. Объекты распределять крайне неэффективно. E>>>объекты распределять и не требуется. G>>А что будет распределяться? E>в интернете этого добра хватает. вон Грег Янг ездит с докладами по миру. сходи, послушай.
Слушал, такой бред рассказывает что смешно.
E>>>более того, в реализацию SOA вполне может лечь ООП. а это значит, что там может быть использован DDD. G>>Не может, ООП как подход проектированию не совместим с SOA, а вот сделать сервисы SOA из классов, вполне может быть, только не ООП это. G>>И где там может быть использован DDD? Покажешь пример?
E>опять какие-то глупости пошли. E>в основе сервисов лежит DDD. это даже у Эванса есть.
А у меня нет, у меня сервиcы без DDD.
E>а иначе что делает сервис? тупо возвращает данные?
Когда надо возвращать — возвращает. Когда надо изменять — изменяет.
E>возможно. в таком случае домен может быть на другой стороне этой цепочки.
На какой другой? На одной стороне хранилище, на другой UI. Идет передача информации от одного к другому.
G>>>>В среднем anemic кода получается меньше, чем rich при той же задаче. О какой простоте поддержки ты говоришь? E>>>а говорил строками код не меряешь. E>>>но меньше кода, не значит лучше. G>>Да, лучше больше функционала, вот anemic и позволяет получить больше функционала за меньше строк (почему-то сходу написал "денег"). G>>А что для тебя "лучше"? E>без проблем. используй анемик. разве тебя кто-то заставляет писать по другому? E>тебя даже никто не пытается переубедить.
Я хочу понять зачем использовать rich.
G>>>>Думаешь если не слушать все вероятность ошибок уменьшится? Думаешь если ты при построении модели для бухгалтерии отбросишь обороты и потом совершенно случайно не сделаешь их, то пользователи останутся довольны? E>>>ты мешаешь всё подряд. у тебя каша в голове. G>>Это я пытаюсь из твоей каши хоть какую-то информацию достать, а то ты вещаешь лозунги с первой страницы domaindrivendesign.org и других сайентологов, не особо вникая о чем они. E>я просто троллю. а ты пыжишься чего-то.
Заметно.
E>>>>>у тебя получится anemic, у меня будет домен. G>>>>Приведи пример, посмотрим. E>>>ты слишком много хочешь. E>>>примеров, полный гугл. G>>Дай ссылку чтоли. E>забанили в гугле?
нет, мне лениво. Дай ссылку и я даже почитаю. А пока твои слова не весомее воздуха.
E>>>>>это в данном случае не важно. мы можем передать признак, можем передать число, равняющееся сумме предыдущих покупок, на основании которого будем делать скидку. G>>>>Это как раз важно, откуда мы передадим это число? E>>>ты в 10 раз задаешь один и тот же вопрос. перечитай тред, ответ там есть. G>>да, ответ там есть: мы число получим в сервисе, а потом передадим в объект, это менее эффективно чем считать скидку в сервисе. Ведь можно получить ту же скидку, не материализуя объект. ты не согласен и сам продолжаешь ходить по-кругу, пытаясь найти преимущества материализации объектов. G>>Вот только нет этих преимуществ.
E>реализация логики в сервисе, это конечно можно. для процедурного программирования. но ООП как бы говорит о другом. и я придерживаюсь последнего подхода, в отличии от тебя.
А зачем ты его придерживаешься, что оно тебе дает?
E>эффективности при решении задач оно не убавляет. для больших проектов выгода очевидна.
Убавляет, тупо потому что больше кода писать надо.
E>и опять ты кидаешься в крайности. для тебя если DDD, то материализовать всё. но это не так.
Ок, приведи пример где это не так. У тебя же логика в классах и без ссылки на класс ты её вызывать не можешь.
E>>>>>проще говоря, добавь покупателю поле с суммой покупок, и получай её сразу с покупателем. G>>>>Нельзя, потому что требуется сумма покупок за последний месяц, то есть вычисление на момент покупки, хранить значение ты не сможешь. E>>>смогу. G>>Ок, покажи как. E>ты и такую задачу реализовать не можешь?
См SQL выше. Его же можно с помощью LINQ нагенерить (что я собственно и сделал в подобной задаче).
E>>>цель — использовать преимущества ООП парадигмы при решении задач. а так же DDD методологии. E>>>но для кого-то функциональное программирование кажется лучшим решением. это его право. и это 2 совершенно разных подхода. G>>Какие это преимущества, ты так и не ответил. У тебя получается преимущество ООП в использовании ООП. Остальное только недостатки. E>о преимуществах написано в соответствующих книгах. я не собираюсь дублировать тут написанное. достаточно прочесть, понять и применять. либо не понять, и распинаться на форуме о том, какое это говно. E>правда хуже оно от того не становится
Так ты опиши их вкратце, а то книги большие, воды там много.
В чем ты видишь преимущества, желательно в цифрах? Или ты просто тупо следуешь тому что в книгах пишут?
E>>>ошибаешься, доменные объекты есть. именно они и решают где и какой update сделать. G>>Каким образом решают? Пример кода приведешь? E>я кажется начинаю понимать. ты прочел Эванса, по диагонали, но как применять не понял. теперь от всех требуешь примеры кода. я угадал?
Нет, я требую примеры кода от таких троллей, которые пишут лозунги и после каждого второго слова ссылаются на эванса, фаулера или еще кого.
Code talks.
E>>>нет, DDD это классическое ООП, и ничего не нарушает. G>> G>>Само по себе конечно не нарушает. Но если следовать фаулеру, то нарушает. Domain Model нарушает SRP как минимум.А если выносить из доменных объектов всю логику в "доменные сервисы", то нарушает принцип бритвы оккама. E>опять глупости понеслись. Domain Model как раз очень четко вписывается в SRP, в отличии от твоих сервисов.
Ага, особенно одновременное совмещение задач по переносу данных и БЛ. Ведь ты можешь разделить эти обязанности без потери других характеристик, это само существование anemic показывает.
E>>>а вот anemic, в общем-то, не является ООП подходом. G>>Почему не является? Там есть классы, есть поведение, инкапсулированное в классах, там есть полиморфизм, основанный на реализации интерфейсов. Вот и докажи что ООП нет? Может быть там нет ОО-дизайна, описанного Бучем и Мейером, так уже давно известно что они довольно плохой дизайн описали по куче формальных признаков. E>на самом деле наличие классов, наследование, полиморфизм и инкапсуляция, абсолютно не делают подход объектно ориентированным. у тебя класс это лишь объединение подобных по смыслу функций.
Да, это называется "инкапсуляция поведения".
E>а вот поведения объектов у тебя нет.
Есть, у меня данных в этих объектах нет.
E>но зато ты и сам подтвердил свою причину непонимания DDD — ты не знаешь что такое ООП и не умеешь его применять на практике. отсюда и процедурный подход, которым ты так гордишься.
Ты расстроешься, но я прекрасно знаю ООП во всех его инкарнациях, именно поэтому оно не вызывает у меня такой бури юношеских эмоций как у тебя.
E>>>в корпоративном секторе ни процедурного, ни функционального подхода для реализации БЛ нет. что очевидно. G>>Не очевидно, докажи. E>если тебе это не очевидно, могу только по соболезновать.
Это тебе соболезновать надо. Ты говоришь глупость, сам в нее свято веришь и при этом не понимаешь тех кто не верит в нее.
Такое бывает у сектантов и у сумасшедших. Хотя апологеты DDD проявляют черты и тех и других
G>Как ты такое будешь хранить? Это надо вычислять.
совершенно необязательно. это достаточно вычислять 1 раз при оформлении пользовательского заказа.
E>>и о ужас! в основе её лежит доменная модель!!! G>не-а, в её основе лежать очереди и воркеры, а доступ к данным может быть абсолютно любым.
вот видишь. то потому что ты видишь только то, что хочешь.
но открою секрет, в середине лежит домен, который обрабатывает команды.
посмотрю любую схему CQRS. там по центру есть такое, Domain Model называется.
E>>своё мнение я сделал сам. и оно меня вполне устраивает. E>>рекомендую тебе заняться тем же самым. G>Так ты его озвучь, а то получается разговор с голосами в твоей голове, которые никто кроме тебя не слышит.
я и не нуждаюсь в том, что бы их кто-то слышал. а вот ты все время добиваешься этого.
G>Слушал, такой бред рассказывает что смешно.
а ты наверное умнее?
E>>опять какие-то глупости пошли. E>>в основе сервисов лежит DDD. это даже у Эванса есть. G>А у меня нет, у меня сервиcы без DDD.
не могу сказать что рад за тебя, но зачем мне эта информация?
E>>а иначе что делает сервис? тупо возвращает данные? G>Когда надо возвращать — возвращает. Когда надо изменять — изменяет.
а логика изменения данных где лежит?
E>>возможно. в таком случае домен может быть на другой стороне этой цепочки. G>На какой другой? На одной стороне хранилище, на другой UI. Идет передача информации от одного к другому.
на третьей, очевидно же.
E>>без проблем. используй анемик. разве тебя кто-то заставляет писать по другому? E>>тебя даже никто не пытается переубедить. G>Я хочу понять зачем использовать rich.
так попробуй понять это. напряги мозг, подумай. иначе никак не получится. никто тебе тут в примерах и сравнениях не покажет чем одно лучше другого, особенно когда оппонент не способен адекватно воспринимать информацию.
E>>>>>>у тебя получится anemic, у меня будет домен. G>>>>>Приведи пример, посмотрим. E>>>>ты слишком много хочешь. E>>>>примеров, полный гугл. G>>>Дай ссылку чтоли. E>>забанили в гугле? G>нет, мне лениво. Дай ссылку и я даже почитаю. А пока твои слова не весомее воздуха.
я кажется и не требовал признания тобой моих слов)
то тебе лень гуглить, то ты пишешь что хочешь понять зачем использовать рич. так хочешь все же, или лень?
E>>реализация логики в сервисе, это конечно можно. для процедурного программирования. но ООП как бы говорит о другом. и я придерживаюсь последнего подхода, в отличии от тебя. G>А зачем ты его придерживаешься, что оно тебе дает?
ответ на этот вопрос уже звучал в этом треде.
так же можешь почитать что-то на тему ООП, наверняка там будут описаны профиты.
E>>эффективности при решении задач оно не убавляет. для больших проектов выгода очевидна. G>Убавляет, тупо потому что больше кода писать надо.
выигрыш не в кол-ве строк, а в гибкости архитектуры.
убавляет только в случаи непонимания ООП и только.
E>>и опять ты кидаешься в крайности. для тебя если DDD, то материализовать всё. но это не так. G>Ок, приведи пример где это не так. У тебя же логика в классах и без ссылки на класс ты её вызывать не можешь.
в CQRS модели шлем команду, обработчик которой вытаскивает при необходимости из базы дополнительные данные и передаёт все это модели, та уже выполняет логику. но варианты могут быть и другие.
E>>ты и такую задачу реализовать не можешь? G>См SQL выше. Его же можно с помощью LINQ нагенерить (что я собственно и сделал в подобной задаче).
это же можно использовать и в DDD. ничто не мешает.
E>>о преимуществах написано в соответствующих книгах. я не собираюсь дублировать тут написанное. достаточно прочесть, понять и применять. либо не понять, и распинаться на форуме о том, какое это говно. E>>правда хуже оно от того не становится G>Так ты опиши их вкратце, а то книги большие, воды там много. G>В чем ты видишь преимущества, желательно в цифрах? Или ты просто тупо следуешь тому что в книгах пишут?
очень тяжело что-то объяснять человеку, который совершенно не понимает ООП, более того, считает при этом его ущербным. это как минимум бесполезное занятие.
по этой причине я не стану ничего писать. но ты можешь прочесть пару книг, возможно это тебе поможет.
G>Нет, я требую примеры кода от таких троллей, которые пишут лозунги и после каждого второго слова ссылаются на эванса, фаулера или еще кого. G>Code talks.
может быть ты начнешь приводить свой код уже? а так же то, как ты видишь, оно должно выглядеть с точки зрения DDD, в твоей интерпретации. тогда предметно поговорим.
E>>опять глупости понеслись. Domain Model как раз очень четко вписывается в SRP, в отличии от твоих сервисов. G>Ага, особенно одновременное совмещение задач по переносу данных и БЛ. Ведь ты можешь разделить эти обязанности без потери других характеристик, это само существование anemic показывает.
доменная модель не переносит никакие данные. она лишь хранит собственное состояние.
тебе уже намекали не один раз, твоя проблема — ты идешь от данных. в ООП нужно идти от модели. по этой причине ты не можешь понять.
E>>на самом деле наличие классов, наследование, полиморфизм и инкапсуляция, абсолютно не делают подход объектно ориентированным. у тебя класс это лишь объединение подобных по смыслу функций. G>Да, это называется "инкапсуляция поведения".
поведение не бывает без состояния, а у тебя его нет, так как ты работаешь в основном с внешними данными.
в конце концов, прочти хотя бы основные паттерны проектирования, и ты поймешь, что они не ложатся на анемичную модель.
а вот структурное программирование более чем.
E>>а вот поведения объектов у тебя нет. G>Есть, у меня данных в этих объектах нет.
я писал выше. у тебя не объект, а сборище методов. в паскале это называлось — модуль.
E>>но зато ты и сам подтвердил свою причину непонимания DDD — ты не знаешь что такое ООП и не умеешь его применять на практике. отсюда и процедурный подход, которым ты так гордишься. G>Ты расстроешься, но я прекрасно знаю ООП во всех его инкарнациях, именно поэтому оно не вызывает у меня такой бури юношеских эмоций как у тебя.
у меня оно вызывает понимание проблемы и её решение. а ты остался на уровне турбо паскаля, чем жутко гордишься. но это твоё дело.
E>>>>в корпоративном секторе ни процедурного, ни функционального подхода для реализации БЛ нет. что очевидно. G>>>Не очевидно, докажи. E>>если тебе это не очевидно, могу только по соболезновать. G>Это тебе соболезновать надо. Ты говоришь глупость, сам в нее свято веришь и при этом не понимаешь тех кто не верит в нее. G>Такое бывает у сектантов и у сумасшедших. Хотя апологеты DDD проявляют черты и тех и других
вот видишь, от собственного бессилия ты начал переходить на личности и хамить. что в очередной раз подтверждает моё мнение о тебе, как довольно слабом программисте.
впрочем, интернет магазины тоже кто-то должен писать.
Здравствуйте, Enomay, Вы писали:
G>>Да, и это уже будет anemic, потому что есть сервис и нет "доменных объектов".
E>ошибаешься, доменные объекты есть. именно они и решают где и какой update сделать.
Ваши доменные объекты занимаются делами вовсе не предметной области.
E>>>насчет размазывания логики по нескольки объектам, ну так это ж банальный принцип "ответственности" из SOLID, да и ООП в целом. так что это правильная реализация. G>>В SOLID куча других принципов, да и за пределами SOLID тоже, и DDD, как его описывает эванс, многое нарушает.
E>нет, DDD это классическое ООП, и ничего не нарушает.
Эванс пишет что есть такие аспекты домена, которые являются отступлением от традиционного ООП. Цитату я приводил.
E>а вот anemic, в общем-то, не является ООП подходом.
С этого и начали этот флейм. Не согласен с категоричностью. Анемик он лишь о сущностях домена а не вцелом о подходе.
E>разные реализации. ты используешь процедурный подход, мы ООП.
Выглядит как гипноз
E>в корпоративном секторе ни процедурного, ни функционального подхода для реализации БЛ нет. что очевидно.
очевидно — в знач. сказуемого совершенно ясно, не вызывает сомнений
Я не первый, у кого вышеописанное вызывает сомнения.
E>>ошибаешься, доменные объекты есть. именно они и решают где и какой update сделать. S>Ваши доменные объекты занимаются делами вовсе не предметной области.
я разве писал что доменный объект сделает update в базе?
E>>а вот anemic, в общем-то, не является ООП подходом. S>С этого и начали этот флейм. Не согласен с категоричностью. Анемик он лишь о сущностях домена а не вцелом о подходе.
смысл фразы ускользает от меня
E>>в корпоративном секторе ни процедурного, ни функционального подхода для реализации БЛ нет. что очевидно. S>
S>очевидно — в знач. сказуемого совершенно ясно, не вызывает сомнений
S>Я не первый, у кого вышеописанное вызывает сомнения.
я не видел таких примеров.
хотя знаю попытки этим заниматься. пока неудачные.
есть примеры реализации 90% логики в базе данных. я считаю это так же можно отнести к процедурному подходу. очень плохое решение, хочу я вам сказать.
Здравствуйте, Enomay, Вы писали:
E>>>ошибаешься, доменные объекты есть. именно они и решают где и какой update сделать. S>>Ваши доменные объекты занимаются делами вовсе не предметной области.
E>я разве писал что доменный объект сделает update в базе?
Что он решает где и какой update сделать.
E>>>а вот anemic, в общем-то, не является ООП подходом. S>>С этого и начали этот флейм. Не согласен с категоричностью. Анемик он лишь о сущностях домена а не вцелом о подходе.
E>смысл фразы ускользает от меня
Смысл в том, что в анемике поведением не обладают лишь объекты домена, что в общем случае не классифицирует анемик как не ООП.
E>>>в корпоративном секторе ни процедурного, ни функционального подхода для реализации БЛ нет. что очевидно. S>>
S>>очевидно — в знач. сказуемого совершенно ясно, не вызывает сомнений
S>>Я не первый, у кого вышеописанное вызывает сомнения.
E>я не видел таких примеров.
Я не видел крокодилов. Очевидно, их нет
E>хотя знаю попытки этим заниматься. пока неудачные. E>есть примеры реализации 90% логики в базе данных. я считаю это так же можно отнести к процедурному подходу. очень плохое решение, хочу я вам сказать.
Очевидно что нет, но сами приводите пример что есть. Пусть и неудачный.
E>>я разве писал что доменный объект сделает update в базе? S>Что он решает где и какой update сделать.
вызов update как следствие работы доменной модели, но не на прямую, конечно же.
E>>смысл фразы ускользает от меня S>Смысл в том, что в анемике поведением не обладают лишь объекты домена, что в общем случае не классифицирует анемик как не ООП.
возьмем 10 процедур. 3 структуры. они друг с другом взаимодействуют. все это написано на Object Pascal. Будет ли это ООП?
взять хотя бы википедию
Объект — некоторая сущность в виртуальном пространстве, обладающая определённым состоянием и поведением, имеет заданные значения свойств (атрибутов) и операций над ними (методов)[1]. Как правило, при рассмотрении объектов выделяется то, что объекты принадлежат одному или нескольким классам, которые в свою очередь определяют поведение (являются моделью) объекта.
я считаю что работа с анемиками в том виде, в котором его тут пропагандируют — это процедурное программирование. если вы считаете иначе, это ваше право. и мне, впрочем, нет никакого до этого дела.
E>>я не видел таких примеров. S>Я не видел крокодилов. Очевидно, их нет
приписываете себе логику блондинки
я о них даже не слышал. и пример никто привести не может. вывод напрашивается сам собой.
Чудеса, ты нашел сервер с бесконечно высокой скоростью, ну ка, поделись этой пулькой 
Мы уже победили, просто это еще не так заметно...
