Здравствуйте, IB, Вы писали:
T>>Ведите себя прилично, не надо переходить на личности. IB>Не надо фаулером на ровном месте прекрываться, если самому сказать нечего.
Мы обсуждаем идеи или личности?
Если идеи, то какая разница, кем она высказана?
Если все-таки личности, то ... пожалуй я воздержусь от подобного обсуждения.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, IB, Вы писали:
T>>>Наследование само по себе (без наличия виртуальных методов) ценности не несет. IB>>Во-первых, несет, во-вторых, T>Кукую?
Полиморфизм достигается не только вирткальными методами в классе.
IB>>какие вообще методы ты хочешь видеть в данных T>Например, методы валидации. Или user-friendly ToString.
Валидация в entity-объектах? Ну это совсем моветон.
T>Пример можно показать, без абстрактных пассов руками в воздухе. По мне так чем объектная модель программы ближе к оной предметной области, тем лучше — проще понимать такой код.
Методы в классах сущностей это ближе к предметной области?
Здравствуйте, gandjustas, Вы писали:
T>>>>Наследование само по себе (без наличия виртуальных методов) ценности не несет. IB>>>Во-первых, несет, во-вторых, T>>Кукую? G>Полиморфизм достигается не только вирткальными методами в классе.
Ну интерфейсы еще есть, конечно, но они тоже не являются частью er-модели.
T>>Например, методы валидации. Или user-friendly ToString. G>Валидация в entity-объектах? Ну это совсем моветон.
Сама реализация валидации может быть расположена и где-то вовне класса, а класс может просто делегировать вызов. Очень удобно, например на SubmitChanges проверять таким образом валидность измененных сущностей.
T>>Пример можно показать, без абстрактных пассов руками в воздухе. По мне так чем объектная модель программы ближе к оной предметной области, тем лучше — проще понимать такой код. G>Методы в классах сущностей это ближе к предметной области?
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>>>Наследование само по себе (без наличия виртуальных методов) ценности не несет. IB>>>>Во-первых, несет, во-вторых, T>>>Кукую? G>>Полиморфизм достигается не только вирткальными методами в классе. T>Ну интерфейсы еще есть, конечно, но они тоже не являются частью er-модели.
Вам наверное стоит разобраться что такое полиморфизм.
T>>>Например, методы валидации. Или user-friendly ToString. G>>Валидация в entity-объектах? Ну это совсем моветон.
T>Сама реализация валидации может быть расположена и где-то вовне класса, а класс может просто делегировать вызов. Очень удобно, например на SubmitChanges проверять таким образом валидность измененных сущностей.
Да уж... Валидацию сущностей надо задавать декларативно — атрибутами или во внешних конфигах. Смотрите Validation Application Block из enterprise library.
T>>>Пример можно показать, без абстрактных пассов руками в воздухе. По мне так чем объектная модель программы ближе к оной предметной области, тем лучше — проще понимать такой код. G>>Методы в классах сущностей это ближе к предметной области? T>Ну да.
С чего это?
Кроме того такие решения обычно нарушают SRP, а преимуществ от них маловато, даже понимаемость кода страдает в таких условиях, за исключением самых простых случаев.
Здравствуйте, gandjustas, Вы писали:
G>>>Полиморфизм достигается не только вирткальными методами в классе. T>>Ну интерфейсы еще есть, конечно, но они тоже не являются частью er-модели. G>Вам наверное стоит разобраться что такое полиморфизм.
Не стоит, я знаю, что такое полиморфизм.
T>>Сама реализация валидации может быть расположена и где-то вовне класса, а класс может просто делегировать вызов. Очень удобно, например на SubmitChanges проверять таким образом валидность измененных сущностей. G>Да уж... Валидацию сущностей надо задавать декларативно — атрибутами или во внешних конфигах. Смотрите Validation Application Block из enterprise library.
Не все проверки стоит делать атрибутами. Иногда это может оказаться overkil-ом.
G>>>Методы в классах сущностей это ближе к предметной области? T>>Ну да. G>С чего это? G>Кроме того такие решения обычно нарушают SRP,
Нарушение SRP можно где угодно усмотреть, было бы желание. Оставишь исключительно данные в сущности — все равно будет нарушение SRP, т.к. класс берет на себя не только ответственность за хранение Name-а, но и LastUpdatedBy. Так что не нужно к этому принципу подходить параноидально, во всем надо знать меру.
G>а преимуществ от них маловато, даже понимаемость кода страдает в таких условиях, за исключением самых простых случаев.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>>>Полиморфизм достигается не только вирткальными методами в классе. T>>>Ну интерфейсы еще есть, конечно, но они тоже не являются частью er-модели. G>>Вам наверное стоит разобраться что такое полиморфизм. T>Не стоит, я знаю, что такое полиморфизм.
Видимо стоит, почитайте http://www.rsdn.ru/forum/message/2853873.aspx
T>>>Сама реализация валидации может быть расположена и где-то вовне класса, а класс может просто делегировать вызов. Очень удобно, например на SubmitChanges проверять таким образом валидность измененных сущностей. G>>Да уж... Валидацию сущностей надо задавать декларативно — атрибутами или во внешних конфигах. Смотрите Validation Application Block из enterprise library.
T>Не все проверки стоит делать атрибутами. Иногда это может оказаться overkil-ом.
"Иногда" это когда? Я только один такой сценарий представляю — когда программа пишется "на выброс".
G>>>>Методы в классах сущностей это ближе к предметной области? T>>>Ну да. G>>С чего это? G>>Кроме того такие решения обычно нарушают SRP,
T>Нарушение SRP можно где угодно усмотреть, было бы желание. Оставишь исключительно данные в сущности — все равно будет нарушение SRP, т.к. класс берет на себя не только ответственность за хранение Name-а, но и LastUpdatedBy. Так что не нужно к этому принципу подходить параноидально, во всем надо знать меру.
Есть обязанность "хранить данные", вот объекты-сущности эти обязанности выполняют независимо от состава полей. Валидация данных, выполнение бизнес-функций — уже другие обязанности, пихать их все в один класс категорически не стоит.
G>>а преимуществ от них маловато, даже понимаемость кода страдает в таких условиях, за исключением самых простых случаев. T>Я так не считаю.
Можете каким-нибудь аргументом подкрепись свое мнение, иначе нет смысла его писать.
Здравствуйте, gandjustas, Вы писали:
G>>>Вам наверное стоит разобраться что такое полиморфизм. T>>Не стоит, я знаю, что такое полиморфизм. G>Видимо стоит, почитайте http://www.rsdn.ru/forum/message/2853873.aspx
Спасибо за беспокойство, но этот пост я уже читал.
T>>Не все проверки стоит делать атрибутами. Иногда это может оказаться overkil-ом. G>"Иногда" это когда?
Когда проверка очень специфична для сущности и реюз этой проверки не предполагается.
G>>>>>Методы в классах сущностей это ближе к предметной области? T>>>>Ну да. G>>>С чего это? G>>>Кроме того такие решения обычно нарушают SRP,
T>>Нарушение SRP можно где угодно усмотреть, было бы желание. Оставишь исключительно данные в сущности — все равно будет нарушение SRP, т.к. класс берет на себя не только ответственность за хранение Name-а, но и LastUpdatedBy. Так что не нужно к этому принципу подходить параноидально, во всем надо знать меру. G>Есть обязанность "хранить данные", вот объекты-сущности эти обязанности выполняют независимо от состава полей.
А данные — это набор атрибутов, следовательно обязанность "хранить данные" — это составная обязанность, которая может быть разбита на более мелкие.
G>Валидация данных, выполнение бизнес-функций — уже другие обязанности, пихать их все в один класс категорически не стоит.
Во всем надо знать меру.
G>>>а преимуществ от них маловато, даже понимаемость кода страдает в таких условиях, за исключением самых простых случаев. T>>Я так не считаю. G>Можете каким-нибудь аргументом подкрепись свое мнение, иначе нет смысла его писать.
Я привел пример, когда это удобно. Посмотри выше по ветке.
Здравствуйте, Tissot, Вы писали:
T>>>Не все проверки стоит делать атрибутами. Иногда это может оказаться overkil-ом. G>>"Иногда" это когда? T>Когда проверка очень специфична для сущности и реюз этой проверки не предполагается.
Получается что часть проверок будет заданы атрибутами\конфигом, а часть в коде методов класса?
Совсем фигня получается. Кроме того вся валидация может быть выполнена используя только публичный контракт класса сущности, еще один повод вынести её отдельно.
Если подсистему валидации нормально продизанить, то получится что-то вроде validation app block.
G>>>>>>Методы в классах сущностей это ближе к предметной области? T>>>>>Ну да. G>>>>С чего это? G>>>>Кроме того такие решения обычно нарушают SRP,
T>>>Нарушение SRP можно где угодно усмотреть, было бы желание. Оставишь исключительно данные в сущности — все равно будет нарушение SRP, т.к. класс берет на себя не только ответственность за хранение Name-а, но и LastUpdatedBy. Так что не нужно к этому принципу подходить параноидально, во всем надо знать меру. G>>Есть обязанность "хранить данные", вот объекты-сущности эти обязанности выполняют независимо от состава полей. T>А данные — это набор атрибутов, следовательно обязанность "хранить данные" — это составная обязанность, которая может быть разбита на более мелкие.
Это уже плод больного воображения.
G>>Валидация данных, выполнение бизнес-функций — уже другие обязанности, пихать их все в один класс категорически не стоит. T>Во всем надо знать меру.
Ага, самоя хорошая мера называется SRP.
G>>>>а преимуществ от них маловато, даже понимаемость кода страдает в таких условиях, за исключением самых простых случаев. T>>>Я так не считаю. G>>Можете каким-нибудь аргументом подкрепись свое мнение, иначе нет смысла его писать. T>Я привел пример, когда это удобно. Посмотри выше по ветке.
Что-то не нашел примеров такого удобства. Кроме того мнимое удобство в одном месте может создать кучу неудобств в других.
На моей первой работе был гениальный класс Queue (очередь), унаследованный от TStringList (на делфи). Содатели этого класса мотивировали удобством, хотя через интерфейс TStringList можно было нарушить работу класса очереди.
Здравствуйте, gandjustas, Вы писали:
T>>Когда проверка очень специфична для сущности и реюз этой проверки не предполагается. G>Получается что часть проверок будет заданы атрибутами\конфигом, а часть в коде методов класса? G>Совсем фигня получается. Кроме того вся валидация может быть выполнена используя только публичный контракт класса сущности, еще один повод вынести её отдельно. G>Если подсистему валидации нормально продизанить, то получится что-то вроде validation app block.
Если ты внимательнее посмотришь validation app block, то увидишь, что в нем предусмотрен вариант для тех случаев, когда сущность сама себя валидирует.
G>>>Есть обязанность "хранить данные", вот объекты-сущности эти обязанности выполняют независимо от состава полей. T>>А данные — это набор атрибутов, следовательно обязанность "хранить данные" — это составная обязанность, которая может быть разбита на более мелкие. G>Это уже плод больного воображения.
Нет, это всего лишь SRP доведенный до конца.
G>>>Валидация данных, выполнение бизнес-функций — уже другие обязанности, пихать их все в один класс категорически не стоит. T>>Во всем надо знать меру. G>Ага, самоя хорошая мера называется SRP.
См. выше.
G>>>Можете каким-нибудь аргументом подкрепись свое мнение, иначе нет смысла его писать. T>>Я привел пример, когда это удобно. Посмотри выше по ветке. G>Что-то не нашел примеров такого удобства. Кроме того мнимое удобство в одном месте может создать кучу неудобств в других.
Очень жаль. Я сделал все, что мог.
G>На моей первой работе был гениальный класс Queue (очередь), унаследованный от TStringList (на делфи). Содатели этого класса мотивировали удобством, хотя через интерфейс TStringList можно было нарушить работу класса очереди.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>Когда проверка очень специфична для сущности и реюз этой проверки не предполагается. G>>Получается что часть проверок будет заданы атрибутами\конфигом, а часть в коде методов класса? G>>Совсем фигня получается. Кроме того вся валидация может быть выполнена используя только публичный контракт класса сущности, еще один повод вынести её отдельно. G>>Если подсистему валидации нормально продизанить, то получится что-то вроде validation app block.
T>Если ты внимательнее посмотришь validation app block, то увидишь, что в нем предусмотрен вариант для тех случаев, когда сущность сама себя валидирует.
Всегда все можно сделать неправильно, и оно при этом даже будет работать.
G>>>>Есть обязанность "хранить данные", вот объекты-сущности эти обязанности выполняют независимо от состава полей. T>>>А данные — это набор атрибутов, следовательно обязанность "хранить данные" — это составная обязанность, которая может быть разбита на более мелкие. G>>Это уже плод больного воображения. T>Нет, это всего лишь SRP доведенный до конца.
Это бред.
G>>>>Валидация данных, выполнение бизнес-функций — уже другие обязанности, пихать их все в один класс категорически не стоит. T>>>Во всем надо знать меру. G>>Ага, самоя хорошая мера называется SRP. T>См. выше.
С каких пор абсурдные высказывания являются аргументом?
SRP придумали не для того чтобы начинающих программистов пугать.
G>>На моей первой работе был гениальный класс Queue (очередь), унаследованный от TStringList (на делфи). Содатели этого класса мотивировали удобством, хотя через интерфейс TStringList можно было нарушить работу класса очереди. T>Неудачный пример.
Почему? Удобно же.
Здравствуйте, Tissot, Вы писали:
T>Кукую?
Про полиморфизм тебе уже рассказали.
T>Например, методы валидации. Или user-friendly ToString.
Ужас какой.
T>Те способы выражения что я знаю, не очень-то приятные для использования.
Во-первых вопрос был не про приятности использования, а про сам факт выражения, а во-вторых, надо уметь готовить
T>Ну это как посмотреть. Кому-то может быть и удобно, мне — не очень.
Ну так это твои личные проблемы.
T>Пример можно показать, без абстрактных пассов руками в воздухе. По мне так чем объектная модель программы ближе к оной предметной области, тем лучше — проще понимать такой код.
Уже трижды говорилось, речь не про объектную модель, а про данные. Data != Object — это то, с чего начинаются все white papers про LINQ и это очень правильно.
Далее, ER на практике, оказывается гораздо ближе к предметной области чем модель данных.
T>По поводу неизменности данных я полностью согласен. А вот по поводу "добавлять, а не менять" — не совсем. Если требования поменялись, то код должен быть тоже поменян, зачем хранить в приложении тот код, который уже не актуален? Не понимаю.
И еще раз. Не код, а данные. Код должен быть поменян, а данные — нет.
Здравствуйте, Tissot, Вы писали:
T>Если идеи, то какая разница, кем она высказана?
Так где идея-то? Ты ее так и не высказал. А фаулер много чего наговорил, как весьма толкового, так и не очень. И очень уж у неофитов на его почве крышу рвет.
Здравствуйте, Tissot, Вы писали:
T>А я цитат и не прошу. Ссылочки будет вполне достаточно.
Ну, считай, что я сослался на фаулера.
T>Очень даже настаивает, когда говорит о сложных приложениях.
Цитату можно? А заодно определение сложных приложений.
T>Ладно, проехали. Нет никакой критики. Вы абсолютно правы.
Ну, а что тогда вообще споришь? Просто потрепаться захотелось? )
T>Нет, ничуть не смешно.
Напрасно...
T> Вложеные TransactionScope-ы реюзают в конечном итоге одну транзакцию, так что множественное число тут не очень уместно.
То есть, больше одной транзакции не бывает?
Продолжай, очень забавная архитектура выстраивается.
Здравствуйте, Tissot, Вы писали:
T>А поточнее ссылочку не подкинешь?
Сразу после того, как перестанешь на фаулера ссылаться и расскажешь что-нибудь сам.
А вообще, читай особенности работы RC в блокировочниках.
T>Не знаю, смотрел профайлером. Ничего особенно криминального не заметил. Все достаточно просто и понятно.
Нету там ничего простого и понятного, если приложение сложнее калькулятора.
T>Для начала сформулировать, что за косяки имеются в виду. Потом — отказаться от EF
Спасибо, я уже.
T>А чего тогда говорить что контроля нет?
Контроля нет в классических ORM и в фаулеровской rich domain model. А LINQ к ним не относится, ты хоть оригинальный-то пост внимательно читал?
S>>>Потом можно напустить профайлер на application tier, чтобы посмотреть, насколько "просто" выполнить селект и распихать по свойствам. T>>Проблема в том, что сравнивать мне придется с тем, чего еще нет. S>Скорее надо сравнивать с тем, чего нет и не будет. В том смысле, что работы, которую ты пронаблюдаешь, в нормальном приложении вовсе быть не должно.
мне кажется что он имел ввиду что ты говоря что все это сложно не говоришь ничего о альтернативе, спор о том какой подход лучше подразумевает сравнение по набору _различных_ характеристик. а предложение посмотреть на какой то подход с определенного угла и "сделать выводы" мягко говоря не конструктивны.
маленько офтоп, но всеже — как то на форуме преобладает позиция втоптать чужое мнение чем продемонстрировать свое.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Tissot, Вы писали:
T>>Кукую? IB>Про полиморфизм тебе уже рассказали.
Дык в том-то и дело, что полиморфизма без методов — нет, а вы ж ратуете за их отсутствие в сущностях.
T>>Например, методы валидации. Или user-friendly ToString. IB>Ужас какой.
Жизнь вообще страшная штука. В Палестине вон людей неповинных убивают почем зря.
T>>Те способы выражения что я знаю, не очень-то приятные для использования. IB>Во-первых вопрос был не про приятности использования, а про сам факт выражения, а во-вторых, надо уметь готовить
Возможно, я не умею их готовить, но почему вы упорно продолжаете умалчивать о том, как это далать?
T>>Ну это как посмотреть. Кому-то может быть и удобно, мне — не очень. IB>Ну так это твои личные проблемы.
Про переходы на личности я уже писал в дугой ветке.
T>>Пример можно показать, без абстрактных пассов руками в воздухе. По мне так чем объектная модель программы ближе к оной предметной области, тем лучше — проще понимать такой код. IB>Уже трижды говорилось, речь не про объектную модель, а про данные. Data != Object — это то, с чего начинаются все white papers про LINQ и это очень правильно.
Ссылки, ссылки, ссылки.
IB>Далее, ER на практике, оказывается гораздо ближе к предметной области чем модель данных.
На вашей практике или не чьей-то еще. Если на чьей-то еще, то с удовольствием об этом почитаю. Накидайте ссылок.
T>>По поводу неизменности данных я полностью согласен. А вот по поводу "добавлять, а не менять" — не совсем. Если требования поменялись, то код должен быть тоже поменян, зачем хранить в приложении тот код, который уже не актуален? Не понимаю. IB>И еще раз. Не код, а данные. Код должен быть поменян, а данные — нет.
А это наверное ваша жена написала в ваше отсутствие?
Во-вторых, добавляя новое поведение, надо его просто добавлять, а не менять старое
Здравствуйте, IB, Вы писали:
T>>Если идеи, то какая разница, кем она высказана? IB>Так где идея-то? Ты ее так и не высказал.
Напомню, что речь шла о использовании domain model. Если вам нужно указание на конкретные страницы, я готов вам сказать номера страниц. Если у вас нет книжки под рукой, я готов в первый рабочий день выслать вам электронный вариант.
Надеюсь, вопрос исчерпан?
IB>А фаулер много чего наговорил, как весьма толкового, так и не очень. И очень уж у неофитов на его почве крышу рвет.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, IB, Вы писали:
IB>>Здравствуйте, Tissot, Вы писали:
T>>>Кукую? IB>>Про полиморфизм тебе уже рассказали.
T>Дык в том-то и дело, что полиморфизма без методов — нет, а вы ж ратуете за их отсутствие в сущностях.
Здравствуйте, IB, Вы писали:
T>>А я цитат и не прошу. Ссылочки будет вполне достаточно. IB>Ну, считай, что я сослался на фаулера.
У меня есть эта книжка. Не мог бы ты назвать раздел в котором говорится об этом? Спасибо
T>>Очень даже настаивает, когда говорит о сложных приложениях. IB>Цитату можно? А заодно определение сложных приложений.
Стр. 52. О том, что я не буду переписывать Фаулера, я уже писал.
Понятие сложности — вопрос сугубо субъективный, никто тебе формулы для вычисления сложности не даст, придется с этим смириться.
T>>Ладно, проехали. Нет никакой критики. Вы абсолютно правы. IB>Ну, а что тогда вообще споришь? Просто потрепаться захотелось? )
По поводу перехода на личности я уже писал. См. выше по ветке.
T>>Нет, ничуть не смешно. IB>Напрасно...
T>> Вложеные TransactionScope-ы реюзают в конечном итоге одну транзакцию, так что множественное число тут не очень уместно. IB>То есть, больше одной транзакции не бывает?
Здравствуйте, IB, Вы писали:
T>>А поточнее ссылочку не подкинешь? IB>Сразу после того, как перестанешь на фаулера ссылаться и расскажешь что-нибудь сам.
Я уже писал, что перепечатывать текст оттуда не буду. Если вас интересуют конкретные вопросы, я готов посмотреть в книге и назвать вам номер страницы.
IB>А вообще, читай особенности работы RC в блокировочниках.
Не мог бы ты расшифровать RC?
T>>Не знаю, смотрел профайлером. Ничего особенно криминального не заметил. Все достаточно просто и понятно. IB>Нету там ничего простого и понятного, если приложение сложнее калькулятора.
Приложение, с которым я работаю сложнее калькулятора. Если вы что-то не понятно в том, что выдает профайлер, можете выслать ваши затруднения сюда, попробуем разобраться.
T>>А чего тогда говорить что контроля нет? IB>Контроля нет в классических ORM и в фаулеровской rich domain model. А LINQ к ним не относится,
Почему LINQ2SQL не может быть отнесен в классическим ORM и почему с его помощью нельзя построить domain model?
IB>ты хоть оригинальный-то пост внимательно читал?
Держите свои эмоции при себе, не надо переходить на личности.
Мы уже победили, просто это еще не так заметно...
