Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>>>Итого, в наличии две модели — модель данных и модель операций над моделью данных. И в каждой из моделей data structures будут разными. Всего то. G>>>>Ага, вот только остается вопрос: какие классы создавать?
I>>>Классы в зависимости от функций каждой модели.
G>>То есть сделать кучу "параллельных" моделей, поддерживать синхронно изменения, перекладывать данные туда-сюда постоянно?
I>Зачем перекладывать ? Модель данных и модель операций — это значит что данных отдельно от операций над ними. Всё. Модель операций может вообще не иметь состояния. Но даже если и имеет, это далеко не всегда значит, что будут какие то параллельные модели где надо синхронизировать изменения.
Понял, "модель операций" это те самые сервисы, которые так любя те кто занимается anemic и не любят те кто занимаются ddd.
G>Понял, "модель операций" это те самые сервисы, которые так любя те кто занимается anemic и не любят те кто занимаются ddd.
Вот всё-таки интересно, кто же "занимается ddd и не любит сервисы"? Откуда это?
Здравствуйте, Baudolino, Вы писали:
L>>Это тебя понесло непойми куда. Прочитай определение уже и пойми, что твое разделение модели данных и кода обработки ее и есть уход от ООП в его классичесом определении ("data structures consisting of data fields and methods together with their interactions"). B>Вообще-то никакого ухода от ООП здесь нет. Логика, затрагивающая несколько сущностей, не обязательно должна быть инкапсулирована в одной из них. Вполне нормально, когда она инкапуслирована в каком-то контексте.
Откуда взялись "несколько сущностей"?
Еще немного, еще чуть-чуть и вы сами зададите вопрос о том, а в чем вообще смысл держать логику рядом с объектом. Где бенефиты?
Здравствуйте, Lloyd, Вы писали:
I>>Account это entity, например такие классы генерит EF ICurrencyRates это конвертор курсов, нужен для перевода средств со счета на счет если у счетов разные валюты. ITrancferPolicy это правила которые определяют как происходит конкретный трансфер.
L>Что Account делает в полях сервиса? Зачем он там?
Для того, что бы сервис выполнял над ним операции. Это ж очевидно — отделение инициализации от операции. Удобно для работы передавать часть параметров в конструкторе, а остальные уже в конкретном методе для конкретной операции.
data structure здесь микс данных на которыми будут выполняться какие то действия и управляющие данные. Оба объекта Account являются частью этой data structure.
Еще вариант вот такой:
var rep = new AccountRepository(Application.Db);
var account1 = rep.LookUpFor(id_1);
var account2 = rep.LookUpFor(id_2);
var svc = new TransferService(Application.CurrencyRates);
svc.Transfer(account1, account2, 100, Currency.USD);
Почему это будет не ОО ? data structure будет немного другой, если точне, то будет хранить только управляющие данные как например ICurrencyRates, ITransferPolicy, а так же все остальные депенденсы которые только могут взяться. В определении ООП ничего не сказано каким должен быть data в data structure. Там используется общий термин, а следовательно подходят все случаи, в т.ч. когда data это управляющие данные.
I>>>>Или ты считаешь, что data structure может состоять только из примитивных типов ? L>>>1. Что такое "примитивные типы"? I>>int, string, double L>Ок.
L>>>2. С чего вы это взяли, что я так считаю? I>>Потому что один раз ты назвал такой подход "менее ооп" L>При чем тут подход? С спрашивал "с чего вы взяли, что я считаю, что data structure может состоять только из примитивных типов"?
Мб. не правильно понял. Но ты ведь не проясняешь свою позицию, только кидаешься общими фразами вроде "читайте определение" и тд. Сэкономь время себе и мне. Не хочешь объяснять — я ж тебя за язык не тяну.
L>>>3. Какое это имеет отношение в тому, что обсуждается? I>>Непосредственное. L>Значит вам не составит труда продемострировать это отношение. Дерзайте.
В моём примере код ты сам углядел это отношение и один из примеров выделил как "более ООП". Я продолжаю ровно ту же тему
L>Откуда взялись "несколько сущностей"?
(Капитан Очевидность) Любой метод класса с одним и более параметрами, равно как любая процедура с двумя и более параметрами, работает с несколькими сущностями. Сущности могут быть одного типа.
L>Еще немного, еще чуть-чуть и вы сами зададите вопрос о том, а в чем вообще смысл держать логику рядом с объектом. Где бенефиты?
Про бенефиты написано много в соответствующей литературе. Рекомендую ознакомиться, чтобы не выдавать одно предложение из википедии за "классическое определение ООП".
Здравствуйте, gandjustas, Вы писали:
G>Понял, "модель операций" это те самые сервисы, которые так любя те кто занимается anemic и не любят те кто занимаются ddd.
Это мягко говоря неправда В книге DDD эванс пишет в т.ч. про сервисы
Здравствуйте, Lloyd, Вы писали:
L>Еще немного, еще чуть-чуть и вы сами зададите вопрос о том, а в чем вообще смысл держать логику рядом с объектом. Где бенефиты?
Вопрос сводитcя к тому, как ты понимаешь слово data в data structure.
Здравствуйте, Baudolino, Вы писали:
L>>Откуда взялись "несколько сущностей"? B>(Капитан Очевидность) Любой метод класса с одним и более параметрами, равно как любая процедура с двумя и более параметрами, работает с несколькими сущностями. Сущности могут быть одного типа.
Повторю вопрос, откуда взялись "несколько сущностей"?
L>>Еще немного, еще чуть-чуть и вы сами зададите вопрос о том, а в чем вообще смысл держать логику рядом с объектом. Где бенефиты? B>Про бенефиты написано много в соответствующей литературе. Рекомендую ознакомиться, чтобы не выдавать одно предложение из википедии за "классическое определение ООП".
Спасибо, родной. Но большинство литературы (включая Эванса) было мною давно прочитано.
А вам я в свою очередь могу порекомендовать не только читать литературу, но и вопросы, которые вам задают. Если вы затрудняетесь ответить, то переходить на личности — не самый лучший способ скрыть это.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Lloyd, Вы писали:
L>>Еще немного, еще чуть-чуть и вы сами зададите вопрос о том, а в чем вообще смысл держать логику рядом с объектом. Где бенефиты?
I>Вопрос сводитcя к тому, как ты понимаешь слово data в data structure.
Да, в этом и есть проблема. Я наерное неудачно использовал это слово.
L>Повторю вопрос, откуда взялись "несколько сущностей"?
Я не понимаю смысл этого вопроса. Они взялись в качестве примера, в котором в рамках объектно-ориентированного подхода разделяются модель предметной области и бизнес-логика. По-моему, очевидно, что в ситуации, когда имеется один объект с парой-тройкой примитивных полей (или N никак не связанных объектов), бизнес-логику выносить некуда и незачем.
Здравствуйте, Baudolino, Вы писали:
B>По-моему, очевидно, что в ситуации, когда имеется один объект с парой-тройкой примитивных полей (или N никак не связанных объектов), бизнес-логику выносить некуда и незачем.
Ок. Предположим, что незачем. Преимущества какие-нибудь есть в "не-вынесении"?
Здравствуйте, Baudolino, Вы писали:
G>>Понял, "модель операций" это те самые сервисы, которые так любя те кто занимается anemic и не любят те кто занимаются ddd. B>Вот всё-таки интересно, кто же "занимается ddd и не любит сервисы"? Откуда это?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>Понял, "модель операций" это те самые сервисы, которые так любя те кто занимается anemic и не любят те кто занимаются ddd.
I>Это мягко говоря неправда В книге DDD эванс пишет в т.ч. про сервисы
L>Ок. Предположим, что незачем. Преимущества какие-нибудь есть в "не-вынесении"?
Я обозначил тривиальный случай ровно потому, что его нет смысла обсуждать — он тривиален. Если вам очень важно знать, каковы плюсы и минусы различных подходов в случае модели с одним объектом, имеет смысл создать отдельную тему в разделе "О жизни". Если это просто способ что-нибудь сказать, но по существу вопроса возражений нет, давайте лучше просто закончим разговор и не будем тратить время.
L>То, что DDD и anemic model — перпендикулярные концепции.
Ну выскажите свои аргументы, если не согласны. Почему DDD исключает или наоборот обязательно подразумевает anemic model?
Здравствуйте, Baudolino, Вы писали:
L>>Ок. Предположим, что незачем. Преимущества какие-нибудь есть в "не-вынесении"? B>Я обозначил тривиальный случай ровно потому, что его нет смысла обсуждать — он тривиален.
Если он тривиальный, то и объяснить преимущества будет очень легко.
B>Если вам очень важно знать, каковы плюсы и минусы различных подходов в случае модели с одним объектом, имеет смысл создать отдельную тему в разделе "О жизни". Если это просто способ что-нибудь сказать, но по существу вопроса возражений нет, давайте лучше просто закончим разговор и не будем тратить время.
Кажется в демагогии этот прием называется "ложная альтернатива", не так ли?
Модель данных и модель операций — это значит что данных отдельно от операций над ними. Всё. Модель операций может вообще не иметь состояния. Но даже если и имеет, это далеко не всегда значит, что будут какие то параллельные модели где надо синхронизировать изменения. 
