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

S>Предлагаю оставить Майка с ВВ обсуждать правильное разграничение репозитория и модели, а также способы сохранить жирность модели путём выноса всех ссылок в отдельные сущности доменной модели.
S>Мой ахтунгометр зашкалило еще 50 постов назад, поэтому я ставлю автопометку на эту тему.
+1
У меня вообще настойчивое желание полтемы в юмор сненсти, так как на трезвую голову эту кашу разгребать у меня никаких сил нет, а так, чисто поржать... ))

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

S>Здравствуйте, IB, Вы писали:
ВВ>>>А по поводу — "полиморфизм классов" и "родовые отношения". Что конкретно непонятно?
IB>>Конкретно непонятно, что эти термины означают и что ты вообще имеешь ввиду, когда говоришь "объектно-ориентировано".
S>Я короче понял, Ваня. Тут пришли два мега-гуру архитектуры.

Я думал у вас запрещено переходить на личности...

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

S>Здравствуйте, Mike Chaliy, Вы писали:

IB>>>Это совершенно отдельный самостоятельный юз-кейс и логично, что под него нужен отдельный набор данных, тем более, что в этом наборе вполне себе переиспользуются структуры созданные ранее, под другие задачи.
MC>>Нет, например глупо выгружать на клинет внутренние айдишники оредер айтемов (тех что от ордера)? Да и вы сами дальше говорите про таймстампы. Или у вас в "стройной" моделе будут еще и таимстампы? И вообще что это за фишка внутреннюю модель системы показывать как публичный контракт?
S>Откуда взялась внутренняя модель?
S>Речь идет о построении внешней модели под конкретный случай. Да, мы изобретаем специальный DTO "Ордер с айтемами" и отдаем его.
Вы говорити про переиспользование сущностей "стройной" модели для пердачи данных. Мне с этим сложно согласиться, так как сущности модели в 98% случаев отличаються от того что хотелось бы передать. "Внутрення" модель — это ваша стройная модель, и меня удивляет что вы ее все время пихаете во внешник контракт.

MC>>Типа для изменениня бизнеспроцеса поменть версию публичного контракта? Ндя.
S>А как вы хотели? Если реальность поменялась?
Я хочу чтобы контракт менялся только тогда когда это нужно, а не тогда когда поменялась бизнес логика.

MC>>Ну и казалось причем тут РЕСТ и синхронизация?
S>При том, что в РЕСТ нет проблемы сверхжесткости контракта, придуманной идиотами-авторами SOAP. Контракт в REST легко расширять обратно совместимым образом.
Судя по всему "мега-архитект" не вкурсе что в SOAP нет ни слова про сверхжесткость контракта данных. SOAP вообще глубоко ложить на то что вы передадите в боди. Даже вебсервисы асп.нет потдерживают этот режим... По ходу, все тоже самое справедливо и для РЕСТ... И никак оно проблемы сложных ДТО не решает.

Здравствуйте, Mike Chaliy, Вы писали:
MC>Я думал у вас запрещено переходить на личности...

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

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

ВВ>>>Save в БД тоже во всем том же отдельном лаере.
IB>>Нет уж, ты от темы не увиливай, ты двавай за свои слова отвечай.
IB>>Куда пихать второй Save, если первый не в отдельном?
S>Это он так витиевато пытается донести вот такой простой пример:

Я вам "так витиевато" пытаютсь донести то, что вообще-то предлагается в той самой концепции, которую вы критикуете. Но судя по реакции — это для вас в новинку

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

S>>Мой ахтунгометр зашкалило еще 50 постов назад, поэтому я ставлю автопометку на эту тему.
IB> +1
IB>У меня вообще настойчивое желание полтемы в юмор сненсти, так как на трезвую голову эту кашу разгребать у меня никаких сил нет, а так, чисто поржать... ))

Да ладно вам, поржать... Когда приходится разгребать все прелести жирного ООП в реальном проекте — совсем несмешно.

Есть свой Framework для разработки приложений для конкретной предметной области.
С достаточно удобной объектной моделью. (MVC, Tools, Commands, Document, Views, Panels, фабрика GUI и т. п.)

Для работы с БД используем ORM.

Для передачи данных WebServices. Они поверх Windows-Service'ов. Кое что написано с использованием C/C++.

Использовали ClickOnce для обновления — збили, написали своё.

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

А>Есть свой Framework для разработки приложений для конкретной предметной области.
А>С достаточно удобной объектной моделью. (MVC, Tools, Commands, Document, Views, Panels, фабрика GUI и т. п.)

А>Для работы с БД используем ORM.

А>Для передачи данных WebServices. Они поверх Windows-Service'ов. Кое что написано с использованием C/C++.

А>Использовали ClickOnce для обновления — збили, написали своё.

Ваша компания не Microsoft называется?

Обычно дороговато выходит создание своих велосипедо в таком количестве.

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

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

S>>>Мой ахтунгометр зашкалило еще 50 постов назад, поэтому я ставлю автопометку на эту тему.
IB>> +1
IB>>У меня вообще настойчивое желание полтемы в юмор сненсти, так как на трезвую голову эту кашу разгребать у меня никаких сил нет, а так, чисто поржать... ))

AJD>Да ладно вам, поржать... Когда приходится разгребать все прелести жирного ООП в реальном проекте — совсем несмешно.

"Общество обиженых анемистов"

УСТАВ

1. Общие положения


• 1.1. "Общество обиженых анемистов" является общественной организацией (некоммерческой общественной организацией), включающей в себя на принципах добровольного участия сторонников анемичных моделей.
• 1.2. Общество обладает собственным уникальным мнением как надо писать програмы.
• 1.3. Общество являеться прямым конкурентом компании 1С, с ее програмным обеспечением 1С Предприятие 8.0.
• 1.4. Общество руководствуется своим пониманием принципов програмирования. В случае отсутвия общепризнаных принципов, общество обязуеться приитянуть что нибуть за уши.


2. Цели, задачи и методы Общества


• 2.1. Основной целью Общества является защита анемичной модели от поясгательств других моделей.
• 2.2. Разработка и внедрение программ, формирующих анемичное мировоззрение;
• 2.3. Для осуществления вышеперечисленных задач Общество планирует применять следующие методы:
— сбор информации про недостатки в других моделях;
— организацию подрывной деятельности в других моделях;
— повсемесном продвижении ДатаСетов как идеальной анемичной модели;
— распространиение информации про потерянные годы работы с дургими моделями;
— публичное сжигание книг по архитектурам корпоративных приложений;

3. Права Общества


• 3.1. Общество имеет четкую неопределенную структуру, в кторой найдеться место любому пострадавшему от ига других моделей.
• 3.2. Общество вправе заниматься распространиением ДатаСетов.
• 3.3. Члены общества не имеют права использвать методы в своих сущностях.
• 3.3. Члены общества должны принимать что наличие атрибутов в классе уже достаточная отвественность. Наличие мтодов тоже.


4. Членство в Обществе


• 4.1. Членом Общества может стать любое лицо, достигшее 18 лет, принимающее его Устав, в той или иной форме обиженное представителями других моделей.
• 4.2. Заявки от индусов с прямолинейным анемичным мышлением рассматриваються в первую очередь.


5. Контроль за деятельностью Общества


• 5.1. Контроль за членами возлагаеться под неусыпное бдение руководства. Основным предметом контроля являються методы в сущностях модели.

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

MC>Я думал у вас запрещено переходить на личности...

А ты сам бы смог доказать преимущества анемичной модели без перехода на личности?

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

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

MC>>Я думал у вас запрещено переходить на личности...

ВВ>А ты сам бы смог доказать преимущества анемичной модели без перехода на личности?

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

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

G>Ваша компания не Microsoft называется?

G>Обычно дороговато выходит создание своих велосипедо в таком количестве.

Нет. Не Microsoft. Просто существующие наработки, не важно кого,
нам не подходят — слишком специфична предметная область.

Поначалу дороговато, потом на конвейер поставлено всё в виде плагинов.
Клепаем один за одним. Не боимся за то, что столкнёмся с трудностями и
всё лаконично и гармончно выходит.

Вот так вот

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

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

G>>Ваша компания не Microsoft называется?

G>>Обычно дороговато выходит создание своих велосипедо в таком количестве.

А>Нет. Не Microsoft. Просто существующие наработки, не важно кого,
А>нам не подходят — слишком специфична предметная область.
И что за предметная область? И что за проект вообще?

А>Поначалу дороговато, потом на конвейер поставлено всё в виде плагинов.
А>Клепаем один за одним. Не боимся за то, что столкнёмся с трудностями и
А>всё лаконично и гармончно выходит.
Все равно сомневаюсь что написание такого количества велосипедов оправдано.

А>Вот так вот

я вот читаю и думаю, — этот разговор имеет смысл. и прикол в том, что длится он так долго не потому что кто-то искренне заблуждается, а кто-то точно знает как нужно, а потому, что нет не то что четких количественных характеристик, а нет даже четкого определения, и если в крайних случаях еще можно говорить что-где, то в граничных аж никак, из-за этого и множество интерпретаций. как на мой взгляд, разговор сводится что-то в духе: это более объектно, а это менее объектно, да нет вы просто фишку не рубите, и не правильно понимаете отцов OOП — они имели в виду вот так, а значит это самый из самых ООП подходов — просто вы забыли об этом подходе и новая трактовка, новой трактовки.

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

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

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

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



А>я вот читаю и думаю, — этот разговор имеет смысл. и прикол в том, что длится он так долго не потому что кто-то искренне заблуждается, а кто-то точно знает как нужно, а потому, что нет не то что четких количественных характеристик, а нет даже четкого определения, и если в крайних случаях еще можно говорить что-где, то в граничных аж никак, из-за этого и множество интерпретаций. как на мой взгляд, разговор сводится что-то в духе: это более объектно, а это менее объектно, да нет вы просто фишку не рубите, и не правильно понимаете отцов OOП — они имели в виду вот так, а значит это самый из самых ООП подходов — просто вы забыли об этом подходе и новая трактовка, новой трактовки.

А>однажды мой руководитель как-то прервал подобную беседу приблизительно такой фразой, а давайте-ка не будем галлюцинировать на галлюцинации. я математик по образованию и для меня подход — вначале определить множество, а потом операции на множестве, более понятный, тогда проблема приобретает реальные границы и количественные характеристики, но ... тогда все становиться более прозаичней и меньше возможностей напирать на авторитет и др.

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

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

Так в том и дело, что адекватных метрик для оценки архитектурного решения не существует.
Есть куча первичных метрик, типа количество строк, связность классов, и прочее. Эти метрики зависят от размеров проекта и учитывать их бессмысленно.
Также есть некоторое количество производных метрик, которые хоть и не зависят от размера проекта, но практически не могут показать хорошесть какого-либо архитектурного решения.


ИМХО если бы можно было объективно построить хотябы отношение порядка (даже не количественную метрику) между используемым подходами, то таких тем как эта не возникало бы.

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

G>Так в том и дело, что адекватных метрик для оценки архитектурного решения не существует.
G>Есть куча первичных метрик, типа количество строк, связность классов, и прочее. Эти метрики зависят от размеров проекта и учитывать их бессмысленно.
G>Также есть некоторое количество производных метрик, которые хоть и не зависят от размера проекта, но практически не могут показать хорошесть какого-либо архитектурного решения.
+1

G>ИМХО если бы можно было объективно построить хотябы отношение порядка (даже не количественную метрику) между используемым подходами, то таких тем как эта не возникало бы.
И можно было бы посадить мартышек-архитекторов за тулзу генерящую архитектуру системы на основе этого отношения порядка (ну, или, нескольких альтернативных вариантов архитектуры).

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

B>Тут что я ещё хочу отметить. Бизнес логика в подавляющем большинстве случаев не является поведением бизнес сущностей. А является процессом, который эти сущности использует. Поэтому всё что ты пишешь правильно, но для случаев, когда сущность, действительно, обладает каким-то поведением. Но во многих примерах поведение приписывается сущности ошибочно. Например, заказ, это всего лишь бумажка с данными. У него нет поведения. И операция "оформить заказ" это поведение оформителя заказов, а не заказа. В свою очередь "оформитель заказов" — сущность, зачастую, напрочь лишенная данных.

Могу лишь уточнить что группировать поведение можно как вокруг объекта действия так и вокруг субъекта. Это становится возможным потому что объекты взаимодействуют, а не просто действуют.

Здравствуйте, Безон, Вы писали:

Б>Могу лишь уточнить что группировать поведение можно как вокруг объекта действия так и вокруг субъекта. Это становится возможным потому что объекты взаимодействуют, а не просто действуют.
О том и речь, что если "формировать" все методы действия над "субъектом" в классе субъекта, то что же из этого выйдет. А выйдет каша.

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

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

M>>В моей реальности тоже алгоритм и его изменения первичны. Но у меня есть шеф. ТЧК. Его эти алгоритмы не интересуют, или точнее стоят на втором месте.
S>Вы просто плохо понимаете, о чем вам толкует шеф.
.....


Целиком и полностью согласен с г-м Sinclair

Нужно понимать, что есть как минимум две задачи, ортогональные друг-другу. Это ввод данных, и это показ данных. Требования к ним совершенно разные.
Но общее у них то, что данные скачут по слоям.
Есть еще обработка данных, но она стоит немного отдельно, поскольку данные в этом случае редко проникают в слой презентации.

Так вот. Для задачи ввода данных очень хорошо подходит объектная модель, более того, богатая объектная модель. Почему? Потому что при вводе данных очень много обработки локального набора данных, в терминах ООП — объекта. Это валидация, пересчет полей, и т.п.
(Кстати, совсем не обязательно хранить алгоритмы обработки внутренних данных в объекте, можно лишь вызывать их оттуда. Но это так, камень в огород противников Rich Model, которые считают скидки в строке заказа.) Здесь на помощь приходит типизированность, инкапсуляция, средства структурирования кода и т.п. Самое главное, что в задаче ввода данных объектная модель очень помогает своей структурированностью (кроме специфических случаев не- или слабоструктурированных данных). Если использовать для ввода данных, к примеру, нетипизированные датасеты, то мы теряем контроль типов, кроме того, логику, локальную для единичных объектов нам помещать опять же некуда (хотя тут спасут датасеты типизированные). Но в любом случае, это все будет выглядеть неестественно и странно, и датасетная природа съест мозг в самом скором времени, особенно, когда кто-нибудь поддастся соблазну ввести зависимости поведения от состояния Новый-Изменен-Удален и т.п. Использование других контейнеров, например, ХМЛ файлов, связано с аналогичными проблемами. Особенно весело становится при необходимости предоставления АПИ во внешний мир.

Задача же показа данных (reporting) уже стоит совсем по-другому. Здесь на первом месте стоит скорость, а на втором гибкость. Обработка данных здесь по большей части массовая. Здесь объекты ни к чему. Потому что логика, которая содержится в объектах, их поведение здесь по большей части бесполезна. Использование объектов здесь даже противопоказано, потому что вносит ненужный оверхеад на преобразование массива данных в массив объектов, а значит страдает скорость, а во-вторых, вынуждает считаться со структурой самих объектов и не позволяет малыми усилиями отойти от нее, а значит, страдает гибкость.

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

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

Почему глупо выгружать айди? Почему глупо выгружать таймстампы? И самый главный вопрос: причем тут стройная модель? Выгрузка идентификаторов — это способ обеспечения идентификации экземпляра объекта. Потому что, например, в .НЕТ реализации распределенных приложений (за исключением, пожалуй, ремоутинга) нет другого стандартного способа идентификации экземпляров, кроме идентификации по данным, причем эту идентификацию нужно реализовывать самому (перекрывать Equals). С таймстампами немного другое, передача таймстампов — это способ, необходимый для реализации сервиса без состояния. Т.к. таймстампы все-равно нужны, и есть всего два места, где их хранить — либо на сервере, либо передавать туда-сюда на клиента.

Кстати, почему бы внутреннюю модель не показывать как публичный контракт?

Кстати, все написанное мной выше писалось в расчете на то, что таймстампы все-таки нужны.
MC>Насколько я понял (я не нашел гдето упоминания слова "синхронизация") вы сами придумали необходимость таймстампов?
MC>Иначе говоря над жирными моделями всегда есть фасады. А фасады возвращают ДТО. Будет ли это ремот фасад или просто сервис лэер роли не играет. У нас уже есть ДТО с достаточным уровнем деталиации. Никуда вобщемто жирная модель не пролитает.
Это верно только если вы не против сервисов с состоянием. Тогда для любого объекта можно создать ДТО с уровнем детализации, необходимым для решения задачи. Однако, если сервисы с состоянием не устраивают, то в ДТО помимо бизнес данных приходится складывать еще и данные, необходимые для восстановления состояния объекта модели