M>>Запрещается наследоваться что бы расширить функционал, запрещается агрегация что бы скрыть лишние свойсвтва объектов, все должно быть по возможности размазано во одном классе.
S>От чего запрещено наследоваться?

На это есть много названных и неназванных причин, но похоже склад ума по всей видимости у шефа такой. Не может он объектами оперировать, а может не хочет. Мне по-началу довелось один проект его разгребать (не он сам писал, но под его чутким руководством), где все в кучу свалено было да еще и MultiThreading. Баги вылазили в непонятных местах. В конце концов заглохло. Тогда, у него просто небыло шансов, заказчик давил, и без его напора и контроля все по объектам распределил и все складно заработало. Сейчас начинает на меня наседать, от ООП подхода отказываться. Максимум на что я могу наедеятся это на расширение через partial class.

S>Ну, вообще-то XPath относительно легко поправить в случае изменения структуры XML, в отличие от кода, который бегает по классам-оберткам.
S>Главный вопрос, который хочется себе задать: а эти классы-обёртки — они для чего?

Ну как сказать, есть много причин. Одна из самых банальных — каждый раз не нужно вспоминать как там этот тэг в XML называется. Ну или изменится Xpath путь к какому-то тегу, что по всему коду потом скакать и отлавливать. Такие ошибки компилятор не ловит. Поважнее аргумент: Xml — закрытый объект, как реагировать на изменения данных этого объекта? Это важно в контекте WPF программы, биндинг вообще то предназначен не для односторонней передачи данных, иногда важно знать что пользователь изменил значение на уровне объекта.

S>А зачем тебе типизированный? Для генерации XML вполне сойдет и нетипизированный.

Тоже несколько (не моих) причин. Ну потому что генерируеца схема XSD, которая может использоваться для валидации данных. Вообще данные храняться только лишь в datasete или в контролах интрефейса. Валидацию данных в ДатаСете получаем автоматически. И потом, типизированный датасет можно расширять через partial class, а значить редуцировать количество ошибок, которые может создать программист. Что-то в этом духе...

M>>Вообще-то это WPF-приложение, где биндинг должен будет осуществлятся к XmlDataProvider. Achtung!!! Даже не ObjectDataProvider! XMLDataProvider — который будет содержать Xml сгенерированный поле XMLT преобразований XML из DataSet.
S>А в чем собственно ахтунг? Ты же не ожидаешь от ObjectDataProvider каких-то чудес в духе Дэвида Блейна?

Собственно выше объяснил: Если мой объект, то могу двусторонней биндинг обрабатывать.

M>>Нет не так. Данные обрабатываются, изменяются, добавляются, вычисляются.
S>Я не о данных, а об UI. Как выглядит надводная часть айсберга? Мой любимый пример — данные о продажах. Весь Input UI — одна (1) форма ввода чека.
S>Зато вот отчетов на этом придумано столько, что оторопеть можно.
S>У тебя сколько use-case для ввода, и сколько use-case для вывода?

У меня одна форма, много табов, ввод одно информации влияет на предствление ввода другой части. Некоторые части вводятся в отдельных модальных диалогах. Все достаточно сложно.

Остальную часть про анемик модель я пока опускаю, потому как надо самому поковыряться.

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

А>На это есть много названных и неназванных причин, но похоже склад ума по всей видимости у шефа такой.
Я не спрашиваю "почему". Я спрашиваю "от чего". В смысле — от каких объектов.

А>Не может он объектами оперировать, а может не хочет. Мне по-началу довелось один проект его разгребать (не он сам писал, но под его чутким руководством), где все в кучу свалено было да еще и MultiThreading. Баги вылазили в непонятных местах. В конце концов заглохло. Тогда, у него просто небыло шансов, заказчик давил, и без его напора и контроля все по объектам распределил и все складно заработало. Сейчас начинает на меня наседать, от ООП подхода отказываться. Максимум на что я могу наедеятся это на расширение через partial class.
Я не понимаю, что именно вы называете "ООП" подходом. Вообще, без ООП на шарпе писать не получится никак — так язык устроен.
Приведите пример, что от чего вы хотели отнаследовать, а злой шеф запретил.

А>Ну как сказать, есть много причин. Одна из самых банальных — каждый раз не нужно вспоминать как там этот тэг в XML называется.
Какой тег?

А>Ну или изменится Xpath путь к какому-то тегу, что по всему коду потом скакать и отлавливать.
А у вас XPath предполагается по всему коду? Сочувствую.
Не понимаю, почему нельзя применить ООП по назначению — сделать класс, ответственный за доставание некоторых данных из XML, и в нем упрятать все нужные XPath запросы.
А>Такие ошибки компилятор не ловит. Поважнее аргумент: Xml — закрытый объект, как реагировать на изменения данных этого объекта? Это важно в контекте WPF программы, биндинг вообще то предназначен не для односторонней передачи данных, иногда важно знать что пользователь изменил значение на уровне объекта.
Тут я пас — я про WPF ничего не знаю.

А>Тоже несколько (не моих) причин. Ну потому что генерируеца схема XSD, которая может использоваться для валидации данных.
Ничего не понимаю. Схема полностью ортогональна типу датасета.
А>Вообще данные храняться только лишь в datasete или в контролах интрефейса. Валидацию данных в ДатаСете получаем автоматически. И потом, типизированный датасет можно расширять через partial class, а значить редуцировать количество ошибок, которые может создать программист. Что-то в этом духе...
А зачем его расширять?

А>Собственно выше объяснил: Если мой объект, то могу двусторонней биндинг обрабатывать.
Ну, тогда возможно XmlDataSource не подойдет. Я не в курсе.

А>У меня одна форма, много табов, ввод одно информации влияет на предствление ввода другой части. Некоторые части вводятся в отдельных модальных диалогах. Все достаточно сложно.
М-м. Наверное, стоит потратить усилия на то, чтобы все стало достаточно просто.

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

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

S>Я не спрашиваю "почему". Я спрашиваю "от чего". В смысле — от каких объектов.
от всех классов, своих и классов библиотеки c#

S>Я не понимаю, что именно вы называете "ООП" подходом. Вообще, без ООП на шарпе писать не получится никак — так язык устроен.

можно. я не имею ввиду объекториентированный арсенал FCL, или ООП которое навязывается (например наследование форм, или USerControl). Имеется ввиду та часть приложения, которая разрабатывается программистом. Вот здесь можно про ООП и его принципы забыть, спихнуть все в кучу в пару классов длинной несколько тысяч строк кода и радоваться этой лапше.

S>Приведите пример, что от чего вы хотели отнаследовать, а злой шеф запретил.

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

А>>Ну как сказать, есть много причин. Одна из самых банальных — каждый раз не нужно вспоминать как там этот тэг в XML называется.
S>Какой тег?
Элементы XML-Документа

А>>Ну или изменится Xpath путь к какому-то тегу, что по всему коду потом скакать и отлавливать.
S>А у вас XPath предполагается по всему коду? Сочувствую.
S>Не понимаю, почему нельзя применить ООП по назначению — сделать класс, ответственный за доставание некоторых данных из XML, и в нем упрятать все нужные XPath запросы.

А>>Такие ошибки компилятор не ловит. Поважнее аргумент: Xml — закрытый объект, как реагировать на изменения данных этого объекта? Это важно в контекте WPF программы, биндинг вообще то предназначен не для односторонней передачи данных, иногда важно знать что пользователь изменил значение на уровне объекта.
S>Тут я пас — я про WPF ничего не знаю.

А>>Тоже несколько (не моих) причин. Ну потому что генерируеца схема XSD, которая может использоваться для валидации данных.
S>Ничего не понимаю. Схема полностью ортогональна типу датасета.

Тоже не понимаю

А>>Вообще данные храняться только лишь в datasete или в контролах интрефейса. Валидацию данных в ДатаСете получаем автоматически. И потом, типизированный датасет можно расширять через partial class, а значить редуцировать количество ошибок, которые может создать программист. Что-то в этом духе...
S>А зачем его расширять?

Не знаю.
Когда я начал обьяснить что логику обработки данных в XML невпихнешь, был дан ответ, что вот расширим DataSet через partial class

А>>Собственно выше объяснил: Если мой объект, то могу двусторонней биндинг обрабатывать.
S>Ну, тогда возможно XmlDataSource не подойдет. Я не в курсе.

А>>У меня одна форма, много табов, ввод одно информации влияет на предствление ввода другой части. Некоторые части вводятся в отдельных модальных диалогах. Все достаточно сложно.
S>М-м. Наверное, стоит потратить усилия на то, чтобы все стало достаточно просто.

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

S>

S>public interface IProjectManagement
S>

Согласен. Это именно этого я и ожидал.

Что мне не нравится в этом подходе:
1) Вместо одного класса получаем целых два. Причем наличие второго неочевидно без прочтения документации. Как следствие увеличение вероятности ошибки при работы с сущностью Проект.
2) Экземпляр проекта очень легко перевести в невалидное состояние (достаточно забыть/не знать про менеджер), элементарно захардкодить поведение в "третьей слева в пятом ряду" странице которая может поломать систему после изменения требований.
Да, можно добавить в IProjectManagement метод Validate(Project project) он решит большинство проблем. Но, ИМХО, лучше не допускать перевода в невалидное состояние защитившись контрактом, чем в рантайме получать ProjectNotValidException.
3) Рано или поздно возникнет вопрос "если я могу изменить проект напрямую, зачем мне менеджер?" (см. PS)




В случае же насыщенной модели этих проблем нет:
1) Разработчик имеет дело только с одним классом (то что внутри там два или три класса его волнует мало).
2) Экземпляр класса защищен контрактом.
3) Отпадает сам собой.

Да, появляются другие (куда ж без них):
1) Сложности с инициализацией восстановленного из базы объекта.
2) Аналогично 1) но в отношении классов менящих состояние объекта (см. пример ниже).
3) Пляски с фабриками, если нам для инициализации объекта нужны сторонние сервисы (такие как IProjectManagement ниже).


Не скажу, что эти проблемы проще. Нет, они даже сложнее. Но они изолированны в сервисных слоях: 1 в DataAccess слое, 2) в Домене, 3) в сервисном слое. Причем 1) и 3) использует функциональность предоставленную самим доменом.
Которые (теоретически) должны редко менятся (особенно при наличии подключаемой функциональности).


S>Но фишка в том, что ты можешь поменять этот класс, не меняя модели данных — например, сделать так, чтобы проверялось отсутствие двойных назначений сотрудников, или отсутствие тройных назначений, или еще что-нибудь. Или, например, можно сделать так, чтобы удаление ProjectLead с проекта было не запрещено, а вместо него автоназначался его заместитель.
Сомнительное приемущество в моем случае (у меня один заказчик) которое можно получить и в насыщенной модели:

public class Project
{
    private IProjectManagement _manager; // как-то инджектится в проект
    
    public Participant ProjectLead
    {
        get {return _projectLead;}
        
        set
        {
            _manager.SetProjectLead(this, value); // каким-то образом менеджер устанавливает свойства
        }
    }
}

P.S. В этом же проекте предыдущие разработчики очень сильно потрудились на тему "изменение состояния объекта в обход менеджеров". Делалось это не сложно: выгружались потроха объекта в XML, он правился нужным образом и заливался назад. Мой коллега (видя что именно так идет работа) так же грешил этим, так как изменить поле в объекте много легче и понятнее, чем добавлять метод в менеджер (мне тяжело было переубедить его в этом, да и то не уверен, что он все до конца осознал). В итоге, нам стоило больших трудов избавиться от таких хардкодов (хотя я не уверен что мы вычистили все такие места).

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

A>1) Вместо одного класса получаем целых два.
Лучше два маленьких класса, чем один большой. За подробностями почему так, отсылаю все к тем же набившим оскомину SRP, OCP, инкапсуляции, принципу минимиации интерфейса, низкой связности и пользе хорошо прописанных формальных контрактов.
Про остальное ниже.

A>Причем наличие второго неочевидно без прочтения документации. Как следствие увеличение вероятности ошибки при работы с сущностью Проект.
A>2) Экземпляр проекта очень легко перевести в невалидное состояние (достаточно забыть/не знать про менеджер), элементарно захардкодить поведение в "третьей слева в пятом ряду" странице которая может поломать систему после изменения требований.
A>Да, можно добавить в IProjectManagement метод Validate(Project project) он решит большинство проблем. Но, ИМХО, лучше не допускать перевода в невалидное состояние защитившись контрактом, чем в рантайме получать ProjectNotValidException.
A>3) Рано или поздно возникнет вопрос "если я могу изменить проект напрямую, зачем мне менеджер?" (см. PS)
Это все паранойя, сейчас объясню почему.
Когда разработчик садится писать код, для решения какой либо бизнес-задачи, эта самая бизнес задача формируется ему не в терминах "вот тебе заказ, сделай с ним то-то", а в терминах "мне нужно получить такую-то информацию из заказов". То есть, на первом месте идет функционал, который надо получить/найти/реализовать, а не объект над которым нужно что-то сделать, соответственно, решать эту задачу он начинает не с "ну вот у меня заказ, что бы с ним сделать", а с "где эта хрень, которую мне надо сделать", как следствие он в первую очередь находит именно нужный сервис/менеджер, а потом уже объект содержащий заказ.
Если же все-таки паранойя не дает спать спокойно, есть комплекс простых средств, рецепт прост и незатейлив:
1. Extension Methods
2. Все объекты стройной модели делаются immutable — все свойства readonly, запись свойств только через конструктор, соответственно, изменение только через создание нового экземпляра. Это накорню убивает все попытки поправить объект напрямую и стимулирует найти нужный сервис. Кроме того, сервис создавший объект имеет гарантию, что этот объект всегда останется в нужном ему состоянии.
3. Грамотное разделение проекта на неймспейсы и тщательное продумыванеи структуры (mast have даже при отсутствии паранойи) — этот пункт позволяет избавиться от документации и изнурительных поисков нужного сервиса. Код вообщем-то не плохо самодокументируется.

A>2) Экземпляр класса защищен контрактом.
Не защищен. Просто контракт стал еще толще, соответственно, больше шансов, что что-то сломается при изменении.

A>3) Отпадает сам собой.
Нет, не отпадает. Объект точно так же можно поменять снаружи, в обход всех методов и никто не запретит это сделать.

A> Но они изолированны в сервисных слоях: 1 в DataAccess слое, 2) в Домене, 3) в сервисном слое.
Стройная модель так же отлично бъется по слоям.

A>Сомнительное приемущество в моем случае (у меня один заказчик) которое можно получить и в насыщенной модели:
A> private IProjectManagement _manager; // как-то инджектится в проект
Ты там выше был против большого количества классов, а большое количество pass thru методов тебя не смущает?
Практически на каждый новый метод в сервисе ты должен менять класс модели и писать заглушку для этого метода там.

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

IB>На всякий случай, еще раз проясню свою позицию, чтобы она дошла до самых отдаленных уголков мозга внимательных читателей...
IB>Я специально старался нигде не затронуть ни NH, ни любой другой ORM инструмент, чтобы не ввязываться в бесполезные религиозные споры. Я лишь констатировал тот факт, что _разработички_ NH являются сторонниками "жирной" модели. О чем недвусмысленно заявлено в их манифесте: "The Entity Framework encourages the Anemic Domain Model anti-pattern by discouraging the inclusion of business logic in the entity classes".

Интересно. Можно узнать кто из разработчиков автор этого открытого письма? Как разработчики NH виляют на принципы NH, который всеголишь порт java-hibernate? Ты снова воюешь с одним инструментом и защищаешь другой, скрывая суть статьи — anemic model > rich model. Зачем? Вроде уже куча копий переломана по поводу инструментов, ветка ну очень внушительная да и к сути статьи данный холивар не имеет отношения.

IB>В отличии от них, я считаю антипаттерном именно Rich модель, а Anemic, как раз очень правильным паттерном. Почему я так считаю, я и описал в данной статье.

Вот если бы ты писал только это — было бы просто чудесно. Но первый прозвучавший лозунг — "создатели NH кормят вас неправильным медом, ешьте правильный мед от создателей EF, да, он не сладкий, но сладкое вредно" уже настолько набил оскомину, что читать не хочется.

А теперь по сути: "жирная" модель при всех ее недостатках обладает своими достоинствами, но я сейчас не об этом противостоянии. Я о том, что NH позволяет использовать обе модели, причем никак не толкая к любой одной из них, по крайней мере все подталкивания которые я видел — косвенные упоминания от тебя, Синклера и Влада2, а я немало почитал блогов о (N)Hibernate.

Теперь зададимся вопросом, почему EF нас подталкивает к использованию anemic model? Оказывается, что для бизнеслогики размещенной в классах сущностей очень быстро наступает момент, когда данных в this становится недостаточно, соответственно логика должна уметь, как минимум, загружать нужные ей данные. Но прямая связь сущности с механизмом ее загрузки довольно хорошо раскритикована многими именитыми арихитекторами. Именно это основной минус rich модели: как только ей понадобились другие сущности, мы тут же начинаем нарушать SRP. Для обхода жесткой связи с загрузкой нужных объектов был придуман трекинг по свойствам, а для борьбы с оверхедом загрузки лишних данных пришлось придумать ленивую загрузку. Так вот именно ее и не реализовали создатели EF. Т.o. использовать rich model в EF можно только ценой просадки производительности (изза отсутствия LL) либо используя вместо трекинга другие механизмы загрузки данных.

Большинство аргументов против NH с которыми я согласен — это аргументы как раз против трекинга и навигационного поиска нужных сущностей. Это действительно очень неприятный механизм, т.к. он в общем случае неэффективно использует механизмы РСУБД и привносит чрезмерно выскокий уровень абстракции над механизмами загрузки данных. Это и есть основное зло ORM с которым стоит бороться. Да, EF может заставить отказаться от него, а может заставить изобрести свой LL велосипед.

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

Z>Интересно. Можно узнать кто из разработчиков автор этого открытого письма?
Гугл тебе поможет, ключевые слова "Vote of no confidence".

Z> Как разработчики NH виляют на принципы NH, который всеголишь порт java-hibernate? Ты снова воюешь с одним инструментом и защищаешь другой,
Вашу мать. Давай цитату, где я хоть слово сказал про гибернейт.
Сколько раз можно повторять, что там было лишь упоминаие, что к числу защитников жирной модели, относятся Фаулер и разработчики Nhibernate. Я специально, для самых занудных даже дисклаймер написал, что возможности гибернейта и любого другого ORM меня не парят вообще ни в одном месте, и я не имею желания и не собираюсь их обсуждать.
Где в этом посте хоть слово именно про гибернейт?

Z>Вот если бы ты писал только это — было бы просто чудесно.
А я только про это и написал. Все остальное — плод воспаленной фантазии защитников NH на ровном месте.

Z>Но первый прозвучавший лозунг — "создатели NH кормят вас неправильным медом, ешьте правильный мед от создателей EF, да, он не сладкий, но сладкое вредно" уже настолько набил оскомину, что читать не хочется.
Не хочется — не читай, никто не заставляет.

Z> Я о том, что NH позволяет использовать обе модели,
Это исключительно проблемы NH.

Z>Именно это основной минус rich модели: как только ей понадобились другие сущности, мы тут же начинаем нарушать SRP.
Принцип SRP начинает нарушаться гораздо раньше.

Z> Т.o. использовать rich model в EF можно только ценой просадки производительности (изза отсутствия LL) либо используя вместо трекинга другие механизмы загрузки данных.
Либо реализовав свой LL, что на самом деле доволно просто. Но это все лирика.
Поинт в том, что в связи с порочностью жирной модели это все лишний функционал.

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

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

Z>>Интересно. Можно узнать кто из разработчиков автор этого открытого письма?
IB>Гугл тебе поможет, ключевые слова "Vote of no confidence".

Z>> Как разработчики NH виляют на принципы NH, который всеголишь порт java-hibernate? Ты снова воюешь с одним инструментом и защищаешь другой,
IB>Вашу мать. Давай цитату, где я хоть слово сказал про гибернейт.
IB>Сколько раз можно повторять, что там было лишь упоминаие, что к числу защитников жирной модели, относятся Фаулер и разработчики Nhibernate. Я специально, для самых занудных даже дисклаймер написал, что возможности гибернейта и любого другого ORM меня не парят вообще ни в одном месте, и я не имею желания и не собираюсь их обсуждать.

Сторонники "Жирной" (Rich) модели (к числу которых относятся и разработчики NHibernate), моментально нашли фатальный недостаток в EF — он провоцирует работать с данными "Стройном" (Anemic) стиле, и принялись с усердием обличать в этом EF...

Ты смешал жирную модель, Фаулера, NHibernate и EF. Последние 3 сущности лишние в в дискуссии anemic/rich. Фаулер описывает rich model как один из подходов, этот дядька тем и хорош, что описывает все подходы, а не доказывает заведомую "лучшесть" одного. Anemic model он называет антипатерном только для pure DDD систем, и в этом есть смысл. Почему лишние EF и NH я уже написал.

IB>Где в этом посте хоть слово именно про гибернейт?

Я обсуждал не только пост, но и статью

Z>>Именно это основной минус rich модели: как только ей понадобились другие сущности, мы тут же начинаем нарушать SRP.
IB>Принцип SRP начинает нарушаться гораздо раньше.

Это лишь твое мнение, что хранение данных достаточная ответственность, чтобы ее выделить в отдельную сущность. Я с ней не согласен. (сам лично последние полтора года использую anemic model, но по другим причинам).

Z>> Т.o. использовать rich model в EF можно только ценой просадки производительности (изза отсутствия LL) либо используя вместо трекинга другие механизмы загрузки данных.
IB>Либо реализовав свой LL, что на самом деле доволно просто. Но это все лирика.
IB>Поинт в том, что в связи с порочностью жирной модели это все лишний функционал.

Ты смешиваешь мух и котлеты. Трекинг и жирность модели пересекаются довольно слабо. Можно сделать жирную модель без трекинга и тощую с трекингом.

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

Z>

Сторонники "Жирной" (Rich) модели (к числу которых относятся и разработчики NHibernate), моментально нашли фатальный недостаток в EF — он провоцирует работать с данными "Стройном" (Anemic) стиле, и принялись с усердием обличать в этом EF...

Так где здесь хоть слово про гибернейт?

Z>Ты смешал жирную модель, Фаулера, NHibernate и EF.
Если тут у кого-то что-то смешалось, то точно не у меня.
Давай еще раз, если по прежнему непонятно: Есть авторы NH, совершенно конкретные люди. Есть Фаулер, тоже конкретный человек, но другой. У них есть мнение и они это мнение высказали. Конкретно у авторов NH есть мнение, что "EF не поддерживает жирную модель, в чем его огромный недостаток, так как жирная модель это хорошо". Упомянул я об этом, чтобы было понятно, что эту точку зрения я взял не с потолка и что действительно есть люди, кторые заблуждаются подобным образом.
Мне по прежнему непонятно, какой еще смысл можно извлечь из процитированного куска и в чем тут смешение, тем более с NH про который вообще ни слова.

Z> Последние 3 сущности лишние в в дискуссии anemic/rich.
Ага, тем более, что одной там вообще нет, а про две другие ты прочитал совсем не то что было написано.

Z> Фаулер описывает rich model как один из подходов,
Фаулер выступает конкретным критиком стройной модели.

Z>этот дядька тем и хорош, что описывает все подходы, а не доказывает заведомую "лучшесть" одного.
В случае жирной модели он занимается именно доказательством ее "лучшести" причем с весьма натянутыми аргументами.

Z> Anemic model он называет антипатерном только для pure DDD систем, и в этом есть смысл.
Ага, толкователи Фаулера подтянулись. В своей критике стройной модели он нигде не упоминает, что речь идет только о DDD.

Z> Почему лишние EF и NH я уже написал.
Лучше бы прочитал сначала, ей богу.

Z>Я обсуждал не только пост, но и статью
Я "статью" и имел ввиду (это все-таки не статья, а пост в блоге), так где там хоть слово про NH? По прежнему жду цитаты.

Z>Это лишь твое мнение, что хранение данных достаточная ответственность, чтобы ее выделить в отдельную сущность.
Это не только мое мнение, это объективная реальность.

Z> Я с ней не согласен.
Твое право, но тем не менее SRP в жирной модели нарушается гораздо раньше.

Z>Ты смешиваешь мух и котлеты.
Z> Трекинг и жирность модели пересекаются довольно слабо. Можно сделать жирную модель без трекинга и тощую с трекингом.
Это ты к чему? Где я хоть слово написал про трекинг?

Слушай у меня вообще складываается ощущение, что ты беседуешь не со мной, а с какими-то своими вольными интерпретациями на заданную тему.
Если что-то непонятно, спроси лучше у меня, а не фантазируй.

так, ну я не знаю как автора вопросов, Aikin-а, а меня данные на них ответы категорически не устроили

A>>2) Экземпляр проекта очень легко перевести в невалидное состояние
IB>Это все паранойя, сейчас объясню почему.
IB>2. Все объекты стройной модели делаются immutable — все свойства readonly, запись свойств только через конструктор, соответственно...
...соответственно, при необходимости переименовать project придется создать новый экземпляр. и что делать с ссылками на старые экземпляры, представляющими ту же самую сущность — ни разу не понятно

A>>2) Экземпляр класса защищен контрактом.
IB>Не защищен. Просто контракт стал еще толще, соответственно, больше шансов, что что-то сломается при изменении.
зато все "опасные" изменения находятся в известном месте — внутри. так что вы застрахованы от ужаса через некоторое время обнаружить что ваш любимый коллега Петя ровным слоем по всему проекту разбросал строки в духе

project.ID++;

и как их теперь найти и повыковыривать — не понятно
это в случае mutable сущностей. в случае immutable — см вопрос выше


PS
IB> В случае жирной модели он занимается именно доказательством ее "лучшести" причем с весьма натянутыми аргументами.
....
Z>Это лишь твое мнение, что хранение данных достаточная ответственность, чтобы ее выделить в отдельную сущность.
IB>Это не только мое мнение, это объективная реальность.
я смотрю у Вас с аргументация ровно такая же как у Мартина. знаете поговорку про бревно в глазу?

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

T>...соответственно, при необходимости переименовать project придется создать новый экземпляр.
T>и что делать с ссылками на старые экземпляры, представляющими ту же самую сущность — ни разу не понятно
Очень даже понятно — либо просто грохнуть, если это кеш, либо обновить, либо вообще ничего не делать, если не актуально.
Вообще, с immutable сущностями как раз проблем нет, проблемы именно с mutable, когда они меняются неожиданно для кода имеющего на него ссылку. При работе со строками у тебя же проблем не возникает?
Да что там строки, есть целые языки, которые отлично себя чувствуют без изменяемых объектов, вся функциональщина на этом построена.

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

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

T>project.ID++;
T>

В том-то и дело, что не застрахованы, так как ID все равно торчит наружу и никто не помешает любимому коллеге сделать тоже самое.

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

IB>При работе со строками у тебя же проблем не возникает?
для строк immutable — это эмуляция поведения value-типа. для сложных объектов (т.е. состоящих из нескольких полей) я себе этого не представляю

IB>Да что там строки, есть целые языки, которые отлично себя чувствуют без изменяемых объектов, вся функциональщина на этом построена.
ну мы ведь не на лиспе пишем сферического коня в вакууме. в том и проблема

T>>зато все "опасные" изменения находятся в известном месте — внутри.
IB>Собственно в этом и проблема. Все что "внутри" никак друг от друга не защищено и где именно внутри стрельнет любое изменение — угадать не возможно, в лучшем случае, пока не отработает соответсвующий юз-кейс.
точно так же как и при использовании Вашего подхода, просто в нашем случае по крайней мере известно где искать грабли

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

T>>project.ID++;
T>>

IB>В том-то и дело, что не застрахованы, так как ID все равно торчит наружу и никто не помешает любимому коллеге сделать тоже самое.
в том то и дело что застрахованы. любому нормальному человеку, пишущему код на основе жирной модели никогда не придет в голову делать поле ID writable. потому что в этом нет никакой необходимости

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

A>2) Экземпляр проекта очень легко перевести в невалидное состояние (достаточно забыть/не знать про менеджер), элементарно захардкодить поведение в "третьей слева в пятом ряду" странице которая может поломать систему после изменения требований.
A>Да, можно добавить в IProjectManagement метод Validate(Project project) он решит большинство проблем. Но, ИМХО, лучше не допускать перевода в невалидное состояние защитившись контрактом, чем в рантайме получать ProjectNotValidException.

Невалидное состояние объекта — это рабочая ситуация. Я не знаю, надо ли кидать ProjectNotValidException — чаще всего должно хватать метода

bool Validate(Project)

. Дело в том, что если у нас есть объект Project — этакая непорочная фифа, которая ни-ни, ни в жисть не окажется в невалидном состоянии — то нам вполне вероятно потребуется таскать нормальный рабочий объект, какой-нибудь ProjectData (либо кучку бесвязных параметров, которые еще нельзя запихать в Project, и которые со временем будут только пухнуть), который можно заполнять по мере возможности (несколько этапов заполнения объекта — через несколько форм ввода, данные приходят из разных сервисов и пр.).

Остальные оба пункта тоже надуманные Преимущества же подхода, когда мы Project ограничиваем контрактом и логику пихаем в этот объект меня только больше убеждают, что так делать все же не стоит.

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

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

T>ну мы ведь не на лиспе пишем сферического коня в вакууме. в том и проблема
На лиспе, к слову GC в .Net написан, так что не надо про сферических коней.. )
Вообщем, если лень проверять, то придется поверить на слово — в реальной жизни от immutable объектов только польза.

T>точно так же как и при использовании Вашего подхода,
Боюсь, ты не очень внимательно читал.

T> просто в нашем случае по крайней мере известно где искать грабли
Я предпочитаю, чтобы за меня их находил компилятор.

T>любому нормальному человеку, пишущему код на основе жирной модели никогда не придет в голову делать поле ID writable. потому что в этом нет никакой необходимости
Ты сам себе противоречишь. Почему в одном случае ID обязательно делать изменяемым, чтобы избежать каких-то мифических проблем с immutable, а в другом этого делать нет никакой необходимости?

Здравствуйте, Torvin, Вы писали:
T>для строк immutable — это эмуляция поведения value-типа. для сложных объектов (т.е. состоящих из нескольких полей) я себе этого не представляю
Для улучшения представлений рекомендую познакомиться с DateTime.
Ты в курсе того, что в Яве приходится со страшной силой приседать, чтобы только не дать стороннему коду надругаться над person.GetBirthday() произвольным образом? Это только потому, что даты в яве — mutable.
Практика применения показывает, что никаких трудностей со сложными датами у программистов не возникает.

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

IB>Слушай у меня вообще складываается ощущение, что ты беседуешь не со мной, а с какими-то своими вольными интерпретациями на заданную тему.
IB>Если что-то непонятно, спроси лучше у меня, а не фантазируй.

Непонятно кто из авторов NH написал Vote of no confidence (прежде чем первый раз спросить, я поискал, гугл дает много ссылок на блоги в которых оно упоминается и не дал мне ссылки на авторов, все что удалось понять, это то, что это плод коллективного разума ALT.NET community. так что ответ "ищи в гугле" меня только позабавил, если бы ты точно знал какого-то автора письма и по совместительству "автора" NH тебя бы не затруднило написать имя). Непонятно почему они записаны в сторонники rich модели (недовольство тем, что инструмент заточен только под одну модель еще не означает упертость человека в другую).
Более менее понятно, почему ты записал туда Фаулера (пусть я и не согласен с тем, что он упертый сторонник rich модели).

Непонятно почему ты не затрудняешь себя аргументацией выдвинутого тобой(?) тезиса:

- Single Responsibility Principle (SRP). Хранение данных в классе — это уже одна, вполне самостоятельная обязанность, добавление другой логики в класс приводит к нарущению этого принципа.

крайне спорное утверждение на мой вгляд

Непонятно почему критикуя rich model ты приводишь в пример ActiveRecord:

Если, следуя логике "жирной" модели, класс с персистентными данными оборудован методом .Save(), сохраняющим данные в БД

Непонятно почему отсутствие возможности LL объявляется провокацией проектировать anemic model (на самом деле оно просто лишает возможностей трекинга).

Непонятно почему однобокость инструмента объявляется достоинством (если бы он был лучше других заточен под anemic model, так ведь нет, просто не умеет LL).

Непонятно почему это утверждение ставится в конце поста, вследствии этого весь пост выглядит как доказательство данного тезиса:

И, возвращаясь к Entity Framework, в свете всего вышеописанного, тот факт, что он "провоцирует" проектировать приложения в "стройной" модели и не поддерживает Lazy Loading, требуя явной загрузки всех необходимых данных, я склонен считать достоинством.

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

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

Z>Непонятно кто из авторов NH написал Vote of no confidence
Конкретно Ayende Rahien тоже в нем учавствовал и подписывал.

Z> так что ответ "ищи в гугле" меня только позабавил,
Ну, не ждешь же ты, что я буду это делаь за тебя?

Z>если бы ты точно знал какого-то автора письма и по совместительству "автора" NH тебя бы не затруднило написать имя).
А то я их всех запоминать буду, вот это действительно было бы забавно.

Z> Непонятно почему они записаны в сторонники rich модели (недовольство тем, что инструмент заточен только под одну модель еще не означает упертость человека в другую).
Ты хоть читал этот Vote? Или ты опять начинаешь вольной трактовкой заниматься? "... The Entity Framework encourages the Anemic Domain Model anti-pattern ...", и прочая риторика направленная на то, что стройный стиль — это отстой, а жирный — рулит всегда, "как подтверджает наш многолетнйи опыт", ага. На мой взгляд трактовка этой петиции конкретная и однозначная — авторы однозначные сторонники жирной модели и критикуют MS за то, что он пошел другим путем. И отмазки — "на самом деле они имели ввиду, что поддержать надо все", смотрятся бледно.

Z>Непонятно почему ты не затрудняешь себя аргументацией выдвинутого тобой(?) тезиса:
Во-первых, потому что я уже устал его аргументировать, если интересно можешь поднять старые флеймы.
А во-вторых, на что собственно приводить аргументы? Твои тезисы "это спорно", тоже аргументацией не блещут, так чего бисер метать?

Z>Непонятно почему критикуя rich model ты приводишь в пример ActiveRecord:
Z>

Если, следуя логике "жирной" модели, класс с персистентными данными оборудован методом .Save(), сохраняющим данные в БД

Ок, понесись по третьему кругу: Потому что метод Save(), в данном случае, ничем не отличается от метода Calculate(), так просто нагляднее.

Z>Непонятно почему отсутствие возможности LL объявляется провокацией проектировать anemic model (на самом деле оно просто лишает возможностей трекинга).
А это вообще не ко мне претензии, а авторам петиции, это их тезис.
Кроме того, это вообще-то две отдельных претензии, и как ты умудрился их смешать — для меня загадка.

Z>Непонятно почему однобокость инструмента объявляется достоинством
По той причине, что лишний и кривой функционал это определенно недостаток. А отсутствие недостатка, в определенном смысле является достоинством.

Z>(если бы он был лучше других заточен под anemic model, так ведь нет, просто не умеет LL).
Где я писал, что он лучше других заточен под стройную модель? Где я вообще писал, что он хоть в чем-то лучше других? (кроме отсутствия лишнего функционала, естетственно)

Z>Непонятно почему это утверждение ставится в конце поста,
Потому что я его там поставил.

Z>вследствии этого весь пост выглядит как доказательство данного тезиса:
И что тебя в данном тезисе неустраивает?

Z>P.S. Непонятна также твоя манера дискутировать. Намекнуть на то, что собеседник псих беседующий со своими фантазиями это нормальный прием?
Ну, начнем с того, что ты сам занимаешься прикладной демагогией — я нигде не намекал, что собеседник псих.
С другой стороны, ты определенно споришь совсем не с тем, что я написал, а с какой-то вывернутой версией, где я затрудняюсь даже воспроизвести логику, которой ты руководствовался, придумывая за меня аргументы.
Выводы из всего этого можно сделать следующие: Либо ты, всетаки, очень хочешь поговорить со мной на тему NHibernate и EF и ORM вообще, и таким сомнительным способом пытаешься вовлечь меня в это дело, ну не вопрос давай тогда откроем отдельный топик, так как к обсуждаемой теме это не имеет никакого отношения. Либо ты пытаешься рассказать мне, что я на самом деле имел ввиду, когда писал этот пост в блоге. В этом случае предлагаю дальнейшую дискуссию прекратить, за очевидной бесполезностью.

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

Z>>Непонятно кто из авторов NH написал Vote of no confidence
IB>Конкретно Ayende Rahien тоже в нем учавствовал и подписывал.
Приятнуто за уши, называть Ayende автором NH как-то странно. Причины: NHibernate всеголишь порт Hibernate, идеологию они не определяют, авторство тут некорректный термин. Подписал документ он аж 29ым, налицо передергивание.

Факт:

документ который содержит строку: "The Entity Framework encourages the Anemic Domain Model anti-pattern by discouraging the inclusion of business logic in the entity classes" подписали 580 человек, в чиcле них и один из разработчиков портирующих hibernate под платформу .NET

Подача:

Сторонники "Жирной" (Rich) модели (к числу которых относятся и разработчики NHibernate), моментально нашли фатальный недостаток в EF — он провоцирует работать с данными "Стройном" (Anemic) стиле, и принялись с усердием обличать в этом EF...

Для красного словца, кстати, выдумана фатальность именно этого недостатка, как будто письмо построено на этой фразе. На самом деле там полно другой критики по существу. Для красного словца же выдумана терминология в стиле плохой/хороший. Это хорошо в предвыборной борьбе, в технической статье как-то странно выглядит. Мало решений на основе PR'а в IT принимается что-ли?

Z>> так что ответ "ищи в гугле" меня только позабавил,
IB>Ну, не ждешь же ты, что я буду это делаь за тебя?
Т.е. ты забыл про кого ты писал и пришлось таки поискать среди авторов разработчика NH?

IB>Ты хоть читал этот Vote? Или ты опять начинаешь вольной трактовкой заниматься? "... The Entity Framework encourages the Anemic Domain Model anti-pattern ...", и прочая риторика направленная на то, что стройный стиль — это отстой, а жирный — рулит всегда, "как подтверджает наш многолетнйи опыт", ага.

Так это единстванная критика. Назвали антипаттерном. Письмо про бузину, а дядьку алкашом обозвали.

IB>На мой взгляд трактовка этой петиции конкретная и однозначная — авторы однозначные сторонники жирной модели и критикуют MS за то, что он пошел другим путем. И отмазки — "на самом деле они имели ввиду, что поддержать надо все", смотрятся бледно.

МС не пошел другим путем. МС всеголишь не реализовал LL, притягивать сюда за уши противостояние anemic/rich можно, но после притягивания надо всетаки закрепить какойнить весомой ссылкой на источник близкий к архитекторам EF.

Z>>Непонятно почему ты не затрудняешь себя аргументацией выдвинутого тобой(?) тезиса:
IB>Во-первых, потому что я уже устал его аргументировать, если интересно можешь поднять старые флеймы.
IB>А во-вторых, на что собственно приводить аргументы? Твои тезисы "это спорно", тоже аргументацией не блещут, так чего бисер метать?

Z>>Непонятно почему критикуя rich model ты приводишь в пример ActiveRecord:
Z>>

Если, следуя логике "жирной" модели, класс с персистентными данными оборудован методом .Save(), сохраняющим данные в БД

IB>Ок, понесись по третьему кругу: Потому что метод Save(), в данном случае, ничем не отличается от метода Calculate(), так просто нагляднее.

Ага, всеглишь небольшая подмена понятий метод из слоя доступка к данным и метод из слоя бизенс логики в данном случае ничем не отличаются. Только пример нагляднее, только не имеет он отношения к проблемам rich model. Ты либо не делаешь разницы между rich model и active record либо пытаешься запутать читателя.

Z>>Непонятно почему отсутствие возможности LL объявляется провокацией проектировать anemic model (на самом деле оно просто лишает возможностей трекинга).
IB>А это вообще не ко мне претензии, а авторам петиции, это их тезис.
IB>Кроме того, это вообще-то две отдельных претензии, и как ты умудрился их смешать — для меня загадка.

А как ты для себя объясняешь факт того, что EF провоцирует проектировать anemic model? Просто поверил на слово?

IB>С другой стороны, ты определенно споришь совсем не с тем, что я написал, а с какой-то вывернутой версией, где я затрудняюсь даже воспроизвести логику, которой ты руководствовался, придумывая за меня аргументы.

Видишь ли, ты не утруждаешь себя аргументами.

Проблема в том, что в "жирной" модели, еще на этапе проектирования приложения нужно не просто обозначить ничего не обязывающую связь один ко многим, между заказом и продуктами в него входящими, а явно сказать, что коллекция объектов OrderItems принадлежит объекту Order

Почему нужно?
Это проблема трекинга, она может быть как в anemic так и в rich model. Можно делать rich без трекинга и anemic с ним. Этой проблеме посвящены три абзаца критикующие rich model.

откуда взят реально революционный для меня тезис?

- Single Responsibility Principle (SRP). Хранение данных в классе — это уже одна, вполне самостоятельная обязанность, добавление другой логики в класс приводит к нарущению этого принципа. Таким образом, вынос логики из класса производится в строгом соответствии SRP.

Я один сомневаюсь в этом утверждении?

IB>Выводы из всего этого можно сделать следующие: Либо ты, всетаки, очень хочешь поговорить со мной на тему NHibernate и EF и ORM вообще, и таким сомнительным способом пытаешься вовлечь меня в это дело, ну не вопрос давай тогда откроем отдельный топик, так как к обсуждаемой теме это не имеет никакого отношения. Либо ты пытаешься рассказать мне, что я на самом деле имел ввиду, когда писал этот пост в блоге. В этом случае предлагаю дальнейшую дискуссию прекратить, за очевидной бесполезностью.

Нет. Мне не нравится некая каша в изложении и я ее критикую, а ты ищешь скрытые мотивы.

Зачем критикую? Может я что-то не так понимаю и мне тут впрявят мозги.

Я в курсе, что тебе нравятся структуры данных максимально повторяющие таблицы (простой мэппинг, отсутствие трекинга).
Я в курсе, что тебе нравится разделять логику обработки и сами данные (anemic модель).

Зачем недостатки трекинга и сложных мэппингов подавать как недостатки rich модели? У нее своих мало чтоли?

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

Z>Приятнуто за уши, называть Ayende автором NH как-то странно.
Z> Причины: NHibernate всеголишь порт Hibernate,
А у порта авторства — нет? Забавно... Код из воздуха появляется, святым байтом. =)

Z> идеологию они не определяют,
Я могу в третий раз повторить — мне плевать на идеологию как гибернейта, так и NH. Сколько можно объяснять, что не о них речь?
Если хочешь об этом поговорить — открывай отдельный топик.

Z>авторство тут некорректный термин.
А какой корректный?

Z> Подписал документ он аж 29ым, налицо передергивание.
Какая разница каким он его подписал? Подписал, значит согласен и поддерживает.

Z>Подача:
Z>

Сторонники "Жирной" (Rich) модели (к числу которых относятся и разработчики NHibernate), моментально нашли фатальный недостаток в EF — он провоцирует работать с данными "Стройном" (Anemic) стиле, и принялись с усердием обличать в этом EF...

И где не соответствие?
"Петиция" обвиняет EF в провокации в стройном стиле? Обвиняет, факт. Разработчики NH согласны с этим обвинением? Согласны, факт.
Что тебя неустраивает?

Z> На самом деле там полно другой критики по существу.
На самом деле по существу там критики нет. Документ на редкость истеричный и все там притянуто зауши. Собственно единственные два пункта по которым вообще имеет смысл дискутировать — это как раз Anemic vs Rich и LL.

Z>Для красного словца же выдумана терминология в стиле плохой/хороший.
Нда.. Это в пику Фаулеровским Rich/Anemic, которые имеют соответствующий оттенок в английском, так что претензии опять не ко мне.

Z>Т.е. ты забыл про кого ты писал и пришлось таки поискать среди авторов разработчика NH?
Я помню, что в составлении этого послания принимал кто-то из NH, им еще активно размахивали как флагом, типа "вон какие люди с нами", я не обязан их помнить поименно.

Z>Так это единстванная критика.
Ты точно этот документ читал? Один пункт возражений из пяти является прямой и непрекрытой пропагандой жирной модели, не замечать этого можно только сознательно искажая. Эта же мысль повторяется и в различных блогах комментаторов, только ты почему-то считаешь по другому, ну, твое право конечно, только какой смысл это здесь обсуждать?

Z>МС не пошел другим путем. МС всеголишь не реализовал LL, притягивать сюда за уши противостояние anemic/rich можно, но после притягивания надо всетаки закрепить какойнить весомой ссылкой на источник близкий к архитекторам EF.
Еще раз тебе говорю — не ко мне претензия. Я одного не понимаю, ты сознательно игнорируешь то что тебе пишут, или просто не читаешь?
То что MS пошел другим путем — это не мое мнение, а мнение авторов петиции, с ними вот и спорь.

Z>Ага, всеглишь небольшая подмена понятий метод из слоя доступка к данным и метод из слоя бизенс логики в данном случае ничем не отличаются.
Так "не отличаются" или "подмена понятий"?

Z>А как ты для себя объясняешь факт того, что EF провоцирует проектировать anemic model? Просто поверил на слово?
Он и в третий раз пошел за елкой. Понимаешь, я не собираюсь объяснять этот факт, мне не интересно откуда его достали. Факт не мой, я тебе устал уже об этом писать. Я его просто взял и прокомментировал, так как считаю нужным. Как я к нему отношусь — это другой вопрос.

Z>Видишь ли, ты не утруждаешь себя аргументами.
Что аргументировать-то? Твои попытки убедить меня в том, что я на самом деле имел ввиду?

Z>Мне не нравится некая каша в изложении и я ее критикую, а ты ищешь скрытые мотивы.
Ты критикуешь не кажу в изложении (хотя она конечно не образец совершенства), а кашу у себя в голове, выдавая ее за мои слова, других объяснений большинству придирок я пока не вижу.

Z>Зачем критикую? Может я что-то не так понимаю и мне тут впрявят мозги.
У тебя странная критика, ты уже на протяжении нескольких сообщений занимаешься прикладной демагогией, обсуждая не сколько аргументацию, сколько мою манеру изложения. По делу было только пара вопросов, на них, если позволишь, отвечу отдельно.

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

Z>Это проблема трекинга, она может быть как в anemic так и в rich model. Можно делать rich без трекинга и anemic с ним. Этой проблеме посвящены три абзаца критикующие rich model.
Z>Зачем недостатки трекинга и сложных мэппингов подавать как недостатки rich модели? У нее своих мало чтоли?
Совершенно верно. Здесь я действительно допустил промашку в изложении, не раскрыв до конца что же именно я понимаю под жирной моделью.
Формально, таки да то что ты называешь "теркингом" может быть как в стройной модели, так и может быть жирная модель без "трекинга". Но на практике, и в многочисленных примерах, я не встречал жирной модели без "трекинга", а про стройную с "трекингом" только упоминания слышал.
Так что в целом да, первая часть поста была посвящена критике организации объектов с необходимостью "трекинга", что по моему мнению является неотъемлимым атрибутом жирной модели, хотя при желании, действительно, можно родить жирную модель без оного.

Z>откуда взят реально революционный для меня тезис?
Революционного в нем ничего нет.

Z>Я один сомневаюсь в этом утверждении?
Есть конечно и другие, так что в целом ты в этом заблуждении не одинок..