Объектный источник данных или выделенный код: что лучше?

Question

Я знаю, что это тема, которая может вызвать много споров, но я хотел бы знать, что люди думают о различных плюсах и минусах использования объектных источников данных. Сейчас я делаю проект с другим программистом, опыт и уровень комфорта которого основаны на классическом ASP, и я не уверен, какой путь пойдет на
а) выполнить работу быстро б) выполнить работу с минимумом суеты

У нас есть хороший уровень хранилища с объектами домена, способными к самопроверке, поэтому существуют методы для привязки ODS или привязки кода.

Мне не нравятся ODS по большинству очевидных причин, но если это избавляет меня от необходимости вручную разбирать код на страницы / сортировать / выбирать / вставлять / обновлять / удалять сценарии, то действительно ли это может быть плохо?

Answer 1

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

Answer 2

Самым большим преимуществом DataSourceControls является то, что они отвлекают некоторые опасения по поводу жизненного цикла .NET, обеспечивая поддержку полного CRUD и двухсторонних выражений привязки данных, то есть <% # Bind ("FirstName")%> (однако двухстороннее). привязка данных отстой, так что вы, вероятно, не пропустите ничего). Как шаблон проектирования, это довольно хорошая идея с посредственной реализацией (во многом как сама WebForms).

Если вы отключаете viewstate и обнаруживаете, что пытаетесь выяснить, почему ваши обратные передачи не обрабатываются, или вам приходится вызывать DataBind () в нескольких местах, источники данных могут снять некоторую головную боль, потому что DataBoundControls достаточно умны, чтобы знать, когда им нужны данные, и они просто требуют их от источника данных. Не требуется никаких вызовов DataBind ().

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

Недостатком источников данных является то, что не было много хороших реализаций. И обычно вы заканчиваете тем, что привязываете свой веб-интерфейс к своей персистентной реализации (то есть SqlDataSource, LinqDataSource и т. Д.) Или в конечном итоге вы используете ObjectDataSource, который отстой, потому что он настолько ограничен, требует жесткого кодирования имен классов и имен методов в ASPX. и использует отражение несколько неэффективно. Из-за этого это не полезно для людей, использующих внедрение зависимостей или статические классы DAO. Это довольно плохо продуманный класс, и он выглядит почти как запоздалая мысль MS.

Лично я бы предпочел использовать источники данных и кодовый код. Используйте DataSource, чтобы убрать головную боль жизненного цикла / состояния представления, а затем предоставьте ему событие «Выбор» в делегатском коде. К сожалению, ObjectDataSource может использовать только отражение, однако вы можете легко написать свою собственную реализацию. У меня есть один из моих собственных, но это не публично. Однако, прежде чем написать это, я использовал это, что компенсирует некоторые недостатки ObjectDataSource:

http://mikeoff.blogspot.com/2006/06/objectdatasource-working-alternative.html

Answer 3

Чем больше вы становитесь знакомыми с используемой базовой платформой ADO.NET, тем меньше и меньше вы будете полагаться на элементы управления источниками данных, которые поставляются с Visual Studio. Я использовал их неукоснительно в первых нескольких проектах .NET, над которыми работал Лучшая попытка сделать это для меня.

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

Answer 4

ObjectDatasource, как и любой другой xxxDatasource в WebForms, является координатором между вашим бизнес-уровнем в больших приложениях (или уровнем доступа к данным в более мелких) и самими элементами управления.

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

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

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

Answer 5

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

Источники данных пользовательских объектов, с другой стороны, очень полезны, поскольку они допускают внутреннее связывание с элементом управления GridView. Набор данных, предоставленный источником данных пользовательских объектов, позволяет легко сортировать и разбивать на страницы. Пользовательский объект также обеспечивает центральное расположение для доступа к уровню данных.

Answer 6

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

Я использую ODS, когда данные будут строго использоваться только для отображения. Нажмите на сетку данных, ODS, и все готово. Но если эти данные нужно каким-либо образом манипулировать, я остаюсь далеко от всех встроенных элементов, ни сеток, ни ODS.

Answer 7

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

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