DAL-> Design :: простая модель против модели & свойство против метода - PullRequest
1 голос
/ 22 августа 2011

Предположим, вы хотите реализовать слой доступа к данным, который позаботится о сохранении вашего (java) объекта в хранилище данных.

Модель в вашем магазине представляет собой сущность (таблица в sql), сущность имеет членов, которые либо содержат информацию о самой сущности, либо отношение к родительской сущности (например, parentId).

Теперь есть следующие случаи:

  1. модель имеет элементы с простыми типами данных (int, char, String).Это самый используемый случай?Вы члены строго типизированы и надежно доступны по всему приложению, но для каждой сущности вам нужен dal.

  2. такой же, как и выше, но для простоты и расширяемости вы решили реализовать свою модель каккарта.Это похоже на API хранилища данных AppEngine.Ваши участники доступны по имени в вашем приложении, но у вас есть один общий dal, и все сущности легко расширяемы.

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

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

Спасибо!

1 Ответ

2 голосов
/ 22 августа 2011

Я бы рекомендовал читать по шаблону агрегаты как часть DDD (доменного дизайна). Основная идея состоит в том, чтобы разделить вашу полную модель сущностей на логические группы, а затем предоставить репозитории для каждого корня совокупности (основной сущности группы), которая сохраняет все сущности, образующие совокупность. Это обеспечивает полное использование ООП, не нарушая при этом проблемы согласованности. В целом я считаю, что это наиболее «организованный» подход.

...