Является ли шаблон DAO широко используемым в .NET?

Является ли объектом доступа к DAO-данным - обычно используемым шаблоном в .NET? Я всегда использовал DAO как способ обеспечить доступ к моему слою данных. Например, у меня может быть тонкий интерфейс над моей EntityFramework ObjectContext, отображающий все мои объекты ObjectSet как IObjectSet.

Затем комплексные запросы будут отображаться DAO, каждый из которых зависит от этого интерфейса. У меня может быть ProductDAO, который предоставляет методы типа GetProductsOnSale() или GetInfrequenlySoldProducts(). Затем мои контроллеры или докладчики будут использовать эти методы, которые, вероятно, будут виртуальными, позволяя выполнять определенные результаты для модульных тестов.

Так что это обычно используемая идиома в .NET? По какой-то причине подавляющее большинство примеров, которые я вижу в Интернете с использованием этого шаблона, основаны на Java. Даже этот вопрос по лучшим методам DAO отмечен как Java, а не С#.

Нет ничего плохого в использовании чего-то из другого сообщества, я просто немного опасаюсь, что все вокруг меня делают вещи по-другому...

Ответ 1

Это распространенная идиома в .NET. Я использовал его и видел, как он использовался во многих местах.

Он встроен в структуру - см. System.Data пространство имен - многие из классов являются базовыми классами для специализированных поставщиков (SQL Server, Oracle, MySQL и т.д.), А операции выполняются в базовых классах.

Однако то, что вы описываете, больше похоже на шаблон хранилища, а не просто использование Объекты доступа к данным.

Это также используется во многих проектах, но не встроено в структуру.

Ответ 2

Я использую шаблон DAO.

Вы упомянули структуру Entity Framework; к этому я бы добавил, что я нахожу DAO намного лучше, чем DataSets и DataTables, которые слишком похожи на базу данных, что недостаточно, как объект для моих вкусов. Например, DataRows нельзя добавить в несколько таблиц данных, поэтому я не могу передавать подмножества загруженных данных на разные объекты, не перемещая их в контейнер, который не был создан для их хранения. (Например, DataRow должен быть в DataTable, но они могут быть только в одном DataTable за раз.) DataRowViews неуклюжи и не так интуитивно понятны, как добавление объектов объекта в другой список.

Ответ 3

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

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

Я написал отдельный блог по этой концепции. Создание общего родового и расширяемого репозитория NHiberate версии 2. Хотя это сообщение в блоге специфично в ссылке NHibernate, вы можете взять те же основные понятия и применить их практически к любому DAO.

Обратите внимание на некоторые инструменты, такие как Entity Framework, Linq2Sql и RavenDB, чтобы назвать их несколькими, они сами выставляют очень уточненные репозитории и могут не обязательно использовать дополнительную оболочку.