SqlDataSource vs ObjectDataSource

Ответ 1

Наличие только SQLDataSource совершенно допустимо, если это просто демо, прототип или быстрый взлом. Это быстро, легко, просто работает и дает вам нужные результаты.

Однако, когда приложение спроектировано и построено в долгосрочной перспективе и предвидит, что вещи (требования, пожелания клиентов, в конечном итоге схема базы данных) могут измениться, тогда может возникнуть больше смысла вводить надлежащий "бизнес" "layer" - моделирует ваши бизнес-объекты как объекты, а затем предоставляет сопоставление от базовой базы данных к этим бизнес-объектам.

Как говорится, вы можете решить почти что угодно в информатике еще одним слоем косвенности (или абстракции) - здесь и здесь.

УВЕРЕННО: вы можете перейти непосредственно к базе данных и, конечно же, сначала и для первой итерации, возможно, (или, возможно,) самым быстрым способом. Но в конечном итоге, когда приложение построено так долго, обычно это быстрый и-грязный способ - стоимость содержания, стоимость обслуживания, затраты и усилия, необходимые для изменения в соответствии с ваши потребности и потребности ваших клиентов будут расти и довольно быстро, это быстрое решение не выглядит таким большим, как с точки зрения усилий.

Итак, чтобы подвести итог моему моменту: да, изначально использование прямого источника данных SQL может быть более быстрым и легким - так используйте его, когда это важно: чтобы сделать что-то для быстрой демонстрации, доказательство концепции стиль приложения. Но в конечном счете, когда вы смотрите на продолжительность жизни приложения, обычно стоит инвестировать немного больше (дизайн и кодирование) усилий, чтобы добавить этот уровень абстракции, чтобы ваши веб-страницы не зависели напрямую от деталей базы данных внизу.

Марк

Ответ 2

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

Если вы идете по этому маршруту, смешивание SQLDataSource и ObjectDataSource может привести к путанице со стороны следующего разработчика, чтобы забрать ваш проект. В этом случае я придерживаюсь ObjectDataSource для согласованности кода.

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

Ответ 3

если вы можете использовать код бизнес-уровня в хранимой процедуре его лучше использовать SQLDataSource

Ответ 4

В теории objectdatasource лучше. Но все зависит от того, насколько хорошо объектная модель написана и документирована. Мы передали на аутсорсинг компанию, которая использовала собственный генератор кода (который они не предоставили нам) для создания всех слоев. Оказалось, что это кошмар, чтобы сделать даже небольшие изменения, такие как добавление свойства или изменение типа поля. Теперь я разбираю практически все, что они сделали, и просто используя хранимые процедуры, которые они написали.

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