Каков наилучший подход к созданию DAL?

Question

Я хочу создать идеальный пользовательский класс DAL (уровень абстракции данных) для использования со всеми моими проектами.

Я искал в интернете и нашел несколько примеров для этого, но никогда не знаю, какой из них лучший.

Это сделать [Attributes]? Или использовать <Generics> или что-то еще?

Так что, пожалуйста, просто дайте мне заголовок, и я пойду оттуда.

Еще раз спасибо и простите мой язык.

Answer 1

Просто убедитесь, что вы:

• Всегда используйте хранимые процедуры
• Никогда не используйте хранимые процедуры
• Иногда используют хранимые процедуры
• Использовать nHibernate
• Использовать SubSonic
• Использовать Entity Framework
• Напишите свой собственный
• Никогда не пиши себе
• Использовать POCO
• Использовать ActiveRecord
• Использовать IRepository
• Всегда делай то, что говорит Фаулер
• Никогда не делай то, что говорит Фаулер
• Не используйте Linq to SQL, он мертв
• Используйте Linq to SQL, он больше не мертв

Сделай все это, и все будет хорошо.

Answer 2

Лучший подход:

Не делайте этого сами , если только это не для академического исследовательского проекта или вы не намерены строить бизнес-подразделения ORM.

Сначала опробуйте десятки существующих решений ORM. (Entity Framework, Subsonic, Nhibernate и т. Д. И т. Д ...). Все они имеют свои причуды и ограничения, смешанные с тоннами удивительности.

ОРМ невероятно трудно понять, и это огромная задача.

Слегка родственные и на деньги: http://wekeroad.com/2009/06/11/youre-not-your-data-access/

Answer 3

Я могу рекомендовать вам сначала прочитать эту статью . И взгляните на Блок приложения доступа к данным библиотеки EnterPrise .

Answer 4

Если вы начинающий, я бы порекомендовал использовать SubSonic (особенно если вы занимаетесь веб-разработкой).

Answer 5

Linq to SQL - лучшее решение, или вы можете попробовать самое простое решение http://fluentado.codeplex.com/

Answer 6

Пожалуйста, прочитайте Особенности проектирования уровня доступа к данным

Answer 7

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

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

SubSonic отлично подходит для небольших, шустрых проектов - как и Linq-to-SQL, если вы используете SQL Server в качестве бэкэнда. Если вам нужна большая корпоративная мощность, вам следует взглянуть на NHibernate, ADO.NET Entity Framework или другие более крупные, более способные игроки (которые слишком сложны и плохо подходят для небольшого, простого сценария).

Я не думаю, что есть THE идеальный способ создания DAL - узнайте, что доступно, узнайте, как выбрать тот, который лучше всего соответствует вашим текущим потребностям, и не изобретайте себя заново - используйте то, что доступно там!

Марк

Answer 8

Определенно не пишите свой собственный менеджер персистентности. Вам следует использовать Object-Relational Mapper (ORM), если вы хотите начать со структуры класса и заставить ORM генерировать структуры таблиц SQL для вас, или использовать SQL Mapper , если Вы хотите начать с таблиц SQL и хотите, чтобы ваши классы представляли строки таблицы.

У меня был большой опыт использования iBatis SQL Mapper и многих людей, таких как Hibernate для ORM (хотя есть кривая обучения).

Мартин Фаулер описывает несколько хороших подходов для написания слоев доступа к данным в Шаблоны архитектуры корпоративных приложений (вот каталог ).

Например, iBatis для .NET использует шаблон Фаулера Table Data Gateway . В iBatis вы указываете объекты шлюза табличных данных в XML. Каждый шлюз обычно управляет доступом к одной таблице SQL, хотя вы также можете выполнять операции с несколькими таблицами. Шлюз состоит из инструкций SQL, каждый из которых содержит немного XML. Каждый SELECT возвращает один или несколько объектов строки, которые представляют собой просто наборы атрибутов плюс методы получения и установки (в .NET они называются POCO или PONO, обычными старыми объектами C # или простыми старыми объектами .NET). Каждый INSERT или UPDATE принимает POCO в качестве входных данных. Это казалось довольно интуитивным и не слишком сложным для изучения.

Answer 9

как уже упоминалось, не пытайтесь внедрить инструмент ORM самостоятельно, многие из них доступны бесплатно. Но DAL не является инструментом ORM, инструмент ORM будет использоваться в вашем DAL. DAL просто для того, чтобы скрыть логику доступа к данным от остальной части вашего приложения, чтобы иметь более поддерживаемое решение. В конце концов, вы также можете иметь нормальные операторы SQL, т.е. ваш класс DAO. При создании DAL следует обратить внимание на то, чтобы максимально отделить его от остальных слоев приложения / других слоев. Это может быть достигнуто путем кодирования с использованием интерфейсов и использования внедрения зависимостей. Spring очень полезен здесь (учитывая вашу программу на Java). Кроме того, нет большой магии при создании такого слоя.