вторник, 15 июля 2014 г.

Анемичная модель и ORM

Анемичная модель и ORM.

Знаете что подумалось?

Что Анемичная модель и ORM это так скажем "если не близнецы-братья", то вещи ОЧЕНЬ связанные.

Анемичная модель это данные с "хелперами" (если я всё правильно понимаю).

Что такое "данные анемичной модели"?

Это "типизированные структуры".

А "хелперы"?

Это "активные классы", которые эти данные умеют обрабатывать.

Что такое ORM? Это "мапинг БД" на классы.

Да?

Стоит ли мапить БД на "активные классы"?

Мне кажется, что НЕ СТОИТ.

По-моему стоит "мапить БД" на "пассивные классы, которые и есть "анемичная модель".

А вот "над мапингом" стоит строить "хелперы", обрабатывающие эту "анемичную модель".

Как-то так...

Это я по своему опыту размышляю...

Ну и про FlyWeight хотелось бы напомнить - http://ru.wikipedia.org/wiki/Flyweight

Update. Сделал тут Dependency Injection для анемичной модели - http://programmingmindstream.blogspot.ru/2014/07/dependency-injection-uml.html
Автор: на

7 комментариев:

  1. Ingword15 июля 2014 г. в 14:40

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

    ОтветитьУдалить
  2. NameRec15 июля 2014 г. в 20:40

    «Что Анемичная модель и ORM это так скажем "если не близнецы-братья", то вещи ОЧЕНЬ связанные.
    Анемичная модель это данные с "хелперами" (если я всё правильно понимаю).»
    -- По-моему - нет. Понятие сервиса не тождественно понятию хелпера.
    Впрочем, всё зависит от того, что Вы понимаете под хелпером.
    Если просто класс-обёртку над какой-то функциональностью, логически привязанной к объектам предметной области, то да - вполне. Просто зачем тогда это называть "хелпером" (в Delphi например, хелпер - некая функциональная надстройка над одним классом, не имеющая собственного состояния).
    Сервис отличается тем, что может оперировать с несколькими объектами (списками и прочими структурами объектов), и вполне может иметь своё состояние. Например, набор параметров операции, которые при её выполнении окажутся в атрибутах объектов, над которыми она определена.
    И вполне можно следовать сервис-ориентированному подходу, не используя никакие ORM.

    Куда поместить бизнес-логику? - В сервисы. Ввести правило, обязывающее (лучше - вынуждающее) оперировать данными исключительно посредством сервисов. Сервисы же структурировать по правилам ООП.

    IMHO: ООП - метод, ORM - способ. Использование конкретного метода, применение заданного способа способа никогда не может быть целью разработки, только - средством достижения цели. - Наверное, это очевидно.
    Хотя зачастую понятия предметной области могут быть представлены объектами в парадигме ООП, совершенно не факт, что применение этой парадигмы даст какой-то выигрыш по сравнению с подходом, ориентированном на данные и операции над ними. Причина в том, что объекты ООП создавались для использования в рамках другого "носителя" - оперативной памяти. Если объекты хранятся в БД, и к ним применяются реляционные операции при их обработке, игнорировать это нельзя. И не следует слишком полагаться на ORM. В простых задачах - возможно. В сложных - приведёт (и приводит!) к росту затрат на разработку, нестабильности и артефактам по производительности. Не говоря уже о постоянной эклектике: "тут у вас объекты, а тут - SQL, поскольку функциональности ORM для этой *экзотической* операции не хватает".
    В этой истории с доменными моделями и ORM, дело поставлено с ног на голову. Сущностям предметной области поставили в соответствие объекты ООП, а раз имеем дело с такими объектами - мы "обязаны" следовать объектной-ориентированной парадигме. - Всё замечательно, но как быть с персистентностью? - Не вопрос! Изобретём ORM.
    Когда становится понятно, что привычному ОО-подходу следовать неудобно (действительно, в корпоративных приложения фокус сосредоточен на операциях и анализе связанных данных, а не на конкретных объектах из доменной модели) "ноги привели" к анемичной модели.
    Если же изменить язык моделирования, отказаться от "тождества" - и сосредоточиться на операциях и выборках - всё становится намного проще.
    Пропадёт инкапсуляция? - Да ничего подобного! Доменная модель - не единственный способ обеспечения инкапсуляции.
    Разнесение бизнес-логики? - Да ничего подобного, хотя всё зависит от того, как писать программу.
    Правда в таком случае придётся изменить фокус уже разработчикам. В этом случае мы имеем дело не с какими-то объектами из доменной модели, но с их совокупностями в таблицах и бизнес-логике, операциях над, в общем случае, множествами записей в этих таблицах.
    Триггеры и транзакции могут оказаться более продуктивным языком моделирования предметной области, чем объекты доменной модели, и ORM как инструмент отражения их представления в БД.

    ОтветитьУдалить
    Ответы
    1. Alex W. Lulin15 июля 2014 г. в 21:48

      Да конечно! В СЕРВИСЫ. Вы правы. Я просто неверно выразился. Слово "хелпер" Delphi "узурпировали под себя". Я просто этим словом давно пользуюсь. Короче - ошибочка вышла.

      Правда к слову "сервис" - тоже можно придраться.

      Но вообще - я ВО МНОГОМ с Вами согласен.

      " "ноги привели" к анемичной модели" - Это я надеюсь не ирония? :-)

      И ещё... Про "меня лично". Говоря "про мой ORM" - не забывайте, что у меня есть "кодогенерация". И Как раз она "диктует" разделение на "данные" и "сервисы". Не просто потому, что так "проще" шаблоны кодогенерации писать.

      Хотя это - не аксиома. Я "по-разному" делаю. В зависимости от задачи.

      Удалить
    2. NameRec15 июля 2014 г. в 23:21

      «" "ноги привели" к анемичной модели" - Это я надеюсь не ирония? :-)»
      -- Да какая уж ирония... :-(
      У меня складывается ощущение, что "полмира" находит, что "доменная модель - наше всё". Кто тут мою иронию воспримет, даже если бы она и была...
      Просто я думаю, что насыщенная модель при усложнении требований и развитии проекта будет естественным образом стремиться к анемичной. Религиозные убеждения - религиозными убеждениями, но когда сроки горят, вера может подождать рефакторинга. Который не случится, к слову :-)

      «И ещё... Про "меня лично". Говоря "про мой ORM" - не забывайте, что у меня есть "кодогенерация". И Как раз она "диктует" разделение на "данные" и "сервисы".»
      -- Ну... Это не моё дело, конечно...
      Но IMHO инструмент не должен диктовать разработчику архитектурные решения...

      Удалить
    3. Alex W. Lulin15 июля 2014 г. в 23:29

      :-)

      Удалить
  3. Ingword15 июля 2014 г. в 23:40

    Причина в том, что объекты ООП создавались для использования в рамках другого "носителя" - оперативной памяти. Если объекты хранятся в БД, и к ним применяются реляционные операции при их обработке, игнорировать это нельзя.

    Подписываюсь полностью.
    Есть вещи которые оптимально делать только в БД.

    ОтветитьУдалить
    Ответы
    1. Alex W. Lulin15 июля 2014 г. в 23:41

      Конечно "есть" :-) Иначе бы и БД бы не было бы :-)

      Удалить

Подписаться на: Комментарии к сообщению (Atom)