Наличие только SQLDataSource вполне допустимо, если это просто демонстрация, прототип или быстрый взлом. Это быстро, легко, просто работает и дает нужные вам результаты.
Однако, когда приложение спроектировано и построено для долгосрочной перспективе и ожидает, что вещи (требования, пожелания клиентов, в конечном итоге схема базы данных) могут измениться, тогда может оказаться гораздо более разумным ввести правильный бизнес. «Слой - смоделируйте свои бизнес-объекты как объекты, а затем предоставьте сопоставление из базовой базы данных с этими бизнес-объектами.
Как говорится, вы можете решить практически все в области компьютерных наук с помощью еще одного слоя косвенности (или абстракции) - здесь тоже самое.
УВЕРЕН: вы можете перейти прямо к базе данных, и, конечно, сначала и для первой итерации это, возможно (или, вероятно), самый быстрый путь. Но в долгосрочной перспективе, когда приложение рассчитано на длительную работу, обычно это быстрый, «грязный» и «грязный» путь - стоимость обслуживания, стоимость обслуживания, затраты и усилия, необходимые для изменения в соответствии с вашим и потребности вашего клиента будут расти и довольно быстро, это быстрое и грязное решение уже не выглядит так здорово с точки зрения усилий.
Итак, чтобы подвести итог моей точке зрения: да, изначально, использование прямого источника данных SQL может быть быстрее и проще - поэтому используйте его, когда это важно: чтобы сделать вещи для быстрой демонстрации, проверки концепции приложение стиля Но в долгосрочной перспективе, когда вы смотрите на срок службы приложения, обычно стоит вложить немного больше (дизайн и кодирование) усилий, чтобы добавить этот уровень абстракции, чтобы ваши веб-страницы не зависели напрямую от деталей база данных внизу.
Марк