ASP.NET DataSet vs Business Objects / ORM

Question

Я думаю о доступе к данным для приложения ASP.NET. Исходя из компании, которая использует множество приложений Windows с наборами данных клиента, существует естественная зависимость от подхода DataSet для работы с данными.

Мне больше нравится подход Business Object, и мне не нравится идея кэшировать DataSet в сеансе, а затем применять обновление.

Есть ли у кого-нибудь опыт / помощь по поводу плюсов и минусов обоих подходов?

Answer 1

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

Другое преимущество уровня доступа к данным (созданного с использованием отдельного проекта / DLL) заключается в том, что он значительно упрощает модульное тестирование. Я также рекомендую вам создать бизнес-уровень, который будет выполнять большую часть обработки данных (например, бизнес-уровень будет отвечать за перетаскивание ObjectDataSources из DAL для передачи в код пользовательского интерфейса). Это не только позволяет инкапсулировать вашу бизнес-логику, но и улучшает тестируемость кода.

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

Обновление: другие участники этой темы продвигают идею использования ORM. Я был бы осторожен с принятием полномасштабного ORM по причинам, которые я ранее обрисовал в общих чертах здесь и здесь . Я делаю согласен, однако, что было бы разумно избегать DataSets. В своей собственной работе я широко использую DataReaders для заполнения моих ObjectDataSources (что тривиально из-за дизайна моего DAL) и считаю его очень эффективным.

Answer 2

DataSets может быть невероятно неэффективным по сравнению даже с другими объектами ADO.NET, такими как DataReaders. Я бы предложил пойти по маршруту BO / ORM, основываясь на том, что вы говорите.

Answer 3

Если вы собираетесь следовать указаниям Microsoft, тогда определенно наблюдается тенденция к LINQ (ORM) против DataSets. Когда появились DataSets (ASP.NET 1.0), LINQ даже не был возможен. С LINQ вы получаете функции безопасности типов и встроенные функции для создания / обновления / удаления из базы данных.

Microsoft даже пыталась упростить переход с помощью LINQ to DataSet .

Answer 4

Ответ Марка Бриттингема точен для двухуровневых приложений. Но что, если я хочу использовать сервисный уровень? Наборы данных являются сериализуемыми. Типизированные DataSets экономят время на ручное кодирование ваших собственных объектов. Типизированные DataSets являются расширяемыми. У Linq to Entities есть проблемы с производительностью, Linq to SQL теперь не работает. Линк для DataSet всегда будет вариант.

Я буду использовать Typed DataSets и многоуровневую архитектуру для экономии времени и организации кода. Я попробовал BO с ручным кодированием, и дополнительное время и время обслуживания не стоят этого.

Answer 5

Компания, в которой я работаю, активно использует DataSets, а также бизнес-уровень. BL в основном загружает наборы данных из БД.

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

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

Но также легко потерять контроль. С этого момента он будет постепенно превращаться в беспорядок.

Оба варианта хороши при правильном использовании. Просто не смешивайте их. Решите сделать это одним способом и следуйте за этим.

Answer 6

Мы собираемся сделать большое обновление для существующего приложения asp, которое интенсивно использовало объекты DataSet; хотя я не с нетерпением жду боли, я буду настаивать на том, чтобы идти по маршруту BO. Одна мысль о том, чтобы заставить работать наборы данных, заставляет меня вспыхивать.

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