.NET: абстрагирование источника данных и текста данных - PullRequest
2 голосов
/ 13 марта 2012

Я пытаюсь написать повторно используемые компоненты для моих наиболее распространенных сценариев разработки:

Я создал универсальный уровень представления для представления объектов домена и объектов данных (dc-serializable) для инкапсуляциив домене-объектах.У меня также есть своего рода состояние / контекст домена, в котором я сохраняю ссылки на все свои экземпляры domainobject.Идея состоит в том, что доменные объекты имеют специальные коллекции, которые заполняются из источника данных при первом обращении по требованию.Это не совсем "DDD", я думаю, но, похоже, это работает ...

В любом случае, теперь я застрял в datacontext и datasource-part.Я много думал о том, как хранить данные и взаимодействовать с источником данных;XML в zip-файлах, sql-серверах, sql-lite-файлах, инфраструктуре сущностей, nhibernate, linqtosql, mongodb и т. д., и я не могу решить, что использовать.Похоже, мне нужно абстрагироваться как от источника данных, так и от текста данных, и вместо этого решить, что использовать в каждом приложении.Важно то, что я не встраиваю жестких зависимостей в конкретные фреймворки.

Реально ли абстрагировать datacontext и источник данных, и при этом все еще работать хорошо и легко со всеми существующими фреймворками?Я думаю об этом неправильно?Это тупик?

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

Гаххх

Обновление:

Я вижу DataContext / DatabaseContext (например, EntityFramework) как модуль / слой для хранения объектов, кэшированных в памяти, выполнения запросов, извлечения и сохранения данных из / в любой источник данных и возврата типизированных объектов потребителю.Это правильно?

В чем разница шаблона репозитория (DDD) и моего DataContext?

Обновление 2:

По сути, этомоя модель (хорошая или плохая?):

DataSource-> DataContext / DataObject-> DomainState / DomainObject-> Presenter

Ответы [ 2 ]

2 голосов
/ 14 марта 2012

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

"Идея состоит в том, что доменные объекты имеют специальные коллекции, которыезаполняется из источника данных при первом обращении к нему по требованию. Я думаю, это не совсем "DDD", но, похоже, оно работает ... "

Чем это отличается от отложенной загрузки?Зачем вам нужен особый тип коллекции?И как это соотносится с DDD?

Реально ли абстрагировать текстовый источник данных и источник данных, и при этом все еще работать хорошо и легко со всеми существующими структурами?Я думаю об этом неправильно?Это тупик?

Нет, это не так (это тупик).Вы можете легко создать модель предметной области, которая не имеет отношения к вашей технологии персистентности, но вам все равно нужно подумать об ограничениях выбранного вами преобразователя orm, например, EF не поддерживает перечисления, nhibernate do.Кроме того, что вы получаете от обобщения этого?Вы никогда не переключаете маппер, если выбрали его, и даже если вы это сделаете, у вас не должно возникнуть проблем с его переключением, если остальная часть вашего решения хороша (не разбрасывайте свой ISession / DbContext / что-либо вокруг и т. Д.).

«В чем разница шаблона репозитория (DDD) и моего DataContext?»

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

Как общее примечание, я хотел быне делай этого сам.Обобщения сложны и почти всегда являются пустой тратой времени.Разработчики любят обобщения и идею «повторного использования кода», но они редко привносят в решение проблемы нечто большее, чем просто запутывание кода и его сложность.Стремитесь создать что-то, что работает и обобщайте, как только вы начнете повторяться.Не пытайтесь создать это заранее, так как вы почти наверняка получите что-то бесполезное (или близко).Кроме того, я не вижу, что вы приносите на стол;Сегодня картографы orm ненавязчивы и просты в использовании.Вы также упомянули общий уровень представления, нет ничего более конкретного, чем представление, поэтому я не вижу в этом и пользы (но, может быть, если вы разместите некоторый код или объясните немного подробнее).

2 голосов
/ 14 марта 2012

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

Это шаблон хранилища прямо здесь.

В чем разница шаблона репозитория (DDD) и моего DataContext?

Хранилище - это способ абстрагировать все, что связано с доступом к хранилищу. Он предназначен для удовлетворения потребностей приложения и получает / отправляет объекты, известные остальной части приложения. DataContext - это деталь реализации EF, которая сама является деталью реализации хранилища.

Хранилище имеет двойное назначение

  1. , чтобы позволить вам изменить способ хранения данных (изменить базу данных, использовать XML-файлы и т. Д.), Предоставляя только интерфейс.

  2. Это освобождает вас от «тиранности» подхода, ориентированного на БД, и позволяет вам сосредоточиться на предметной области. Это очень важно, потому что каждый раз, когда вы начинаете проектировать приложение сначала со схемой db, вы неизбежно пытаетесь вписать в него остальную часть приложения, и у вас будет анемичный домен, имитирующий схему базы данных.

DataSource-> DataContext / DataObject-> DomainState / DomainObject-> Presenter

В любом приложении у вас есть запросы (чтения) и обновления (записи). В 99% домен применяется только для записей, поскольку операции чтения не имеют бизнес-правил (без поведения), вам просто нужно выбрать соответствующие данные для отображения.

Так что для записи я бы предложил этот поток

ViewModel (входная информация) -> Обработка домена (сущности, службы и т. Д.) -> Репозиторий домена

В зависимости от приложения вы можете переходить от модели представления к сущности домена разными способами. Если домен очень прост, вам практически не понадобится домен, модель представления будет доменом, который во многих случаях будет совпадать со схемой db.

Для чтения

Репозиторий запросов -> ViewModel (Presenter)

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

...