Абстрагирование уровня доступа к данным от бизнес-объекта

Question

Нет ничего нового в том, чтобы отделить код доступа к данным от ваших бизнес-объектов, но я всегда в поиске «лучшего способа» чего-то достичь.

У меня есть следующие классы:

Оранжевый - это мой бизнес-объект.

OrangeList - это список апельсинов.

Пользователь извлекает объекты Orange из хранилища данных, вызывая OrangeList.Fetch (someCriteria). Поэтому OrangeList должен иметь ссылку на уровень доступа к данным - поэтому он имеет свойство: IDataProvider MyDataProvider.

Это будет работать для меня, но проблема в том, что мы не можем получить один апельсин сам по себе - нам всегда нужно пройти через OrangeList.

Либо тот, либо и Orange, и OrangeList должны были бы происходить от какого-то общего объекта, который содержал бы DataProvider.

Является ли это проблемой, или мой подход в первую очередь не подходит?

Любые намеки / указатели приветствуются, спасибо.

РЕДАКТИРОВАТЬ: В свете обсуждения ниже, я проверил шаблон репозитория.

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

ТАК .... Хранилище - это то, как Я ПОЛУЧАЮ Апельсины и СОХРАНЯЮ Апельсины, но все еще не знаю КАК. Я делегирую это IDataProvider, который может быть рядом из перечисленных на диаграмме.

Чтобы уточнить - Orange НЕ умеет извлекать / обновлять себя, верно? Это чистый бизнес-объект - и в этом ли смысл?

альтернативный текст http://img22.imageshack.us/img22/2460/repositorya.jpg

Если вам интересно, мой «LegacyDataProvider» должен поддерживать OLD-систему, которая обращается к базе данных на основе файлов (FoxPro, eek) - но это позволяет мне обернуть это и держать его на расстоянии вытянутой руки от моего новый код.

С точки зрения построения сборки .NET, для предотвращения циклических ссылок похоже, что у меня будет Repository.DLL [OrangeRepo], DataProviderInterface.DLL [IDataProvider] и BusinessObjects.dll [Orange]. Все хорошо?

У меня тогда появилась идея хранилища?

Answer 1

Я предлагаю Шаблон репозитория

Answer 2

Я бы (и делал) составлял бы все эти вещи из основного объекта API (OrangeCart?), Который также составляет объект интерфейса для уровня доступа к данным. Ваши апельсины и списки OrangeList знают, что они принадлежат OrangeCart, и обращаются к нему для выполнения операций DAL.

Answer 3

Вместо OrangeList (некоторые критерии) у меня будет Oranges.Criteria1List, Oranges.Criteria2List. Для одного экземпляра у меня будет Oranges.GetItem (orangeId).

Делая это по-своему, BusinessObject в конечном итоге нужно думать в логических терминах проектирования данных, а не в концептуальных терминах.

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