DAL «Типизированные наборы данных» или настраиваемый бизнес-объект

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

Я бы предложил ORM , например Entity Framework или Nhibernate.

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

Некоторые другие связанные вопросы, которые могут вас заинтересовать

Каковы преимущества использования ORM?

ASP.NET DataSet и Business Objects / ORM

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

• Необходимо иметь возможность чтение источников данных SQL Server, MS Access и FoxPro
• Доступ к SQL Server осуществляется только через вызовы SPROC (не мой выбор)
• Относительно прост в освоении, особенно для разработчиков, плохо знакомых с ASP.NET

Лично я исследовал низкоуровневый доступ к ado.net, типизированные наборы данных, linq-to-sql и простое написание пользовательских классов доступа к данным. Я еще не смотрел на Entity Framework, так как версия, включенная в VS2008, казалось, имела некоторые неоднозначные отзывы, и у меня не было доступа к VS2010 до недавнего времени (я планирую просмотреть EF где-то в этом году).

Мы решили использовать типизированные наборы данных, потому что они, казалось, предлагали более быструю разработку по сравнению с SPROCS, и мы нашли очень подробное руководство Скотта Митчелла по asp.сетевой сайт: http://www.asp.net/data-access/tutorials.

Что касается нашего опыта до сих пор, он в основном был хорошим. Конструктор набора данных генерирует огромный объем кода даже для небольшого количества таблиц (<20). Внесение изменений в SPROCS вызвало несколько головных болей, но я хотел бы, чтобы мне показали инструмент, который облегчил бы эту задачу.

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

Использование ADO .NET Entity Framework, за которым будущее Microsoft ORM. Или рассмотрите вариант с открытым исходным кодом, такой как NHibernate...

HTH.

Лично я предпочитаю настраиваемые бизнес-объекты из-за их гибкости, но это требует больше работы. Также посмотрите на Entity Framework и Linq To Sql. Entity Fx обладает гораздо большей гибкостью в .NET 4.0. Эта статья поможет вам начать работу с Entity Fx.

Лично я согласен с Джоэлом Этертоном, условно.

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

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

Тем не менее, я согласен вместе с Джоэлом Этертоном напишите самый простой наименьший дал, который вы можете реализовать с помощью LINQ, дал всегда слишком важен, чтобы делать его чрезмерно сложным, когда его можно избежать.

NHibernate. Особенно, если вы используете Oracle.

Если что-то, я думаю, вам следует изучить Entity Framework. Существует множество отличных руководств, которые помогут вам начать работу.

С появлением платформы .Net 4.0 и введением LINQ to SQL я перешел на настраиваемый DAL строго написанных бизнес-объектов. Мы немного поэкспериментировали с Entity Framework, но в конечном итоге пришли к выводу, что он очень похож на наборы данных в том смысле, что автоматически сгенерированный код, хотя и удобен, слишком раздут дополнительным мусором, который мы в конечном итоге не использовали.

Мы обнаружили, что запись LINQ в наш DAL и извлечение данных в наши пользовательские классы позволяют упростить доступ к данным и функционально контролировать использование данных. Это был очень удобный процесс, но младшим разработчикам потребовалось немного времени, чтобы усвоить его.

Если вы не хотите тратить время зря, не изучайте наборы данных. Изучите общие концепции объектно-реляционного отображения, их плюсы и минусы. Посмотрите на такие проекты, как Hibernate для Java или Doctrine для PHP. Подходы, лежащие в основе DataTables и DataSets, которые обеспечивают только упаковку объектов базы данных, закончились. Ваша структура должна помочь вам разработать модель предметной области, а не схему базы данных.