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

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

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

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

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

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

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

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

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

Самым большим преимуществом 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