Как определить разницу между бизнес-моделью и моделью данных?

Question

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

Я думаю, что меня смущает, хотя большинство моделей моделей сочетают обе эти роли и на поверхности, которые она чувствует естественным образом. Часто методы, которые изменяют состояния объектов, находятся внутри самих этих объектов. Наверное, у меня есть проблема с примером того, как это работает в реальном мире. Кажется более естественным, что методы изменения объекта находятся внутри этого объекта. Может ли кто-нибудь объяснить это немного более ясно?

Answer 1

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

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

Answer 2

«Бизнес-модель» и «Модель данных» могут рассматриваться как подэтажицы уровня «М» в приложении MVC. Они оба связаны с сохранением и загрузкой данных. Разница в том, что первый ближе к тому, как конечные пользователи видят требования и функциональные возможности, а второй ближе к манипуляциям с базами данных низкого уровня.

Уровень модели данных всегда зависит от конкретного способа, которым данные сохраняются в приложении. Начиная с базы данных (или какой-либо конкретный способ сохранения данных - это могут быть плоские файлы или XML), это первый, наименее абстрактный уровень программного обеспечения. Например, если вы используете Oracle RDBMS для приложения, модель данных - это место, где вы бы указали какую-либо особенность Oracle, например, конкретные инструкции SQL, соединение и т. Д. Это также место для реализации обработки атомных данных (например, инструкции CRUD SQL). Конечно, есть способы сделать этот уровень менее зависимым от данной РСУБД, например, использовать какую-то библиотеку ORM, такую ​​как Hibernate (Java), NHibernate (.NET) или Doctrine (PHP).

Будучи настолько «низким уровнем», модель данных НЕ должна использоваться непосредственно остальной частью приложения. Это роль бизнес-модели.

Бизнес-модель размещена в верхнем абстрактном уровне. Он реализует службы, которые инкапсулируют все функциональные требования, необходимые для приложения.

Бизнес-модель не должна зависеть от конкретной СУБД - она ​​должна использовать модель данных для выполнения этой работы. Другое отличие состоит в том, что он предоставляет менее гранулированные методы - не CRUD-материал, а более сложную, зависящую от бизнеса функциональность. Разумеется, он также не должен зависеть от уровня представления (представления и контроллеры).

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

Но имейте в виду, что это описание «по книге» - сценарии реального мира различны. Иногда нам может не понадобиться два разных уровня данных - например, шаблон ActiveRecord может использоваться как класс Data Model, так и бизнес-класс.В этом случае вы бы смешивали оба уровня в один, но я определенно не рекомендовал бы использовать этот подход для более сложных сценариев.

Answer 3

Модель в реализации MVC является или должна быть бизнес-моделью.

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

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

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

Хотя модель данных может быть на логическом уровне, а затем более близка к бизнес-модели OO, в этом контексте мы обычно говорим о технической реализации логической модели. (Одно ключевое различие: логические модели допускают отношения M-N между таблицами, нормализованная техническая модель будет иметь таблицу ссылок, которая имеет отношение N-1 к двум исходным таблицам).

Внешний вид бизнес-модели OO не сопоставляется непосредственно с нормализованной таблицей и дизайном столбцов. Библиотеки ORM (Object - Relational-Mapping) часто используются для сопоставления атрибутов классов с таблицами и столбцами в реляционной базе данных.

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

Например, вопреки ответу rsenna, я бы сказал, что изменение зарплаты для одного сотрудника по-прежнему зависит от бизнес-модели, даже если оно меняет ее на буквенное значение, поскольку бизнес-модель может определять все виды сдержек и противовесов, валидации и других бизнес-правил для изменения зарплаты сотрудника. Например, у бизнеса могут быть правила, согласно которым заработная плата не может быть изменена более чем на x процентов, никогда не превысит зарплату генерального директора, не будет соответствовать правилам Союза и т. Д.

Хотя разработчики с централизованными базами данных и многие dba не согласятся, эти типы правила принадлежат бизнес-модели, а не модели данных. DBa предпочитает их в модели данных, возможно, потому, что бизнес-модель обычно реализуется на каком-то языке программирования, а модель данных в базе данных и dba - как держать свои базы данных красивыми, действительными и последовательными.

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