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

Question

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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

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

Например, вопреки ответу Рсенны, я бы согласился с тем, что изменение зарплаты для одного сотрудника все еще является функцией бизнес-модели, даже если она меняется на буквальную.ценность, потому что бизнес-модель может определять все виды сдержек и противовесов, проверки и других бизнес-правил для изменения заработной платы сотрудника.Например, бизнес может иметь правила, согласно которым никакая зарплата не может измениться более чем на x процентов, никогда не может превышать зарплату генерального директора, соответствовать правилам Union и т. Д.Вид правил принадлежит бизнес-модели, а не модели данных.DBa предпочитает их в модели данных, возможно потому, что бизнес-модель обычно реализуется на каком-то языке программирования, а модель данных в базе данных, а dba предпочитает, чтобы их базы данных были хорошими, действительными и согласованными.

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

Answer 3

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

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