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

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

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

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

ОТВЕТЫ

Ответ 1

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

По-моему, оба имеют свое место, свои сильные и слабые стороны. Сохраненная временем кодировка элементов, о которых вы упоминаете, в частности подкачки и сортировка, - это большая помощь, но если вы хотите сделать что-нибудь интересное с ними, они быстро начинают бороться.

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

Ответ 6

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

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

Ответ 7

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

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

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

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