Почему я должен использовать N-уровневый подход, когда использование SqlDatasource ОЧЕНЬ ЛЕГКО?

Question

Когда дело доходит до веб-разработки, я всегда старался работать SMART, а не HARD. Итак, в течение долгого времени My Aproach для взаимодействия с базами данных в моих проектах AspNet было так:

1) Создать мои хранимые процедуры

2) Перетащите элемент управления SQLDatasource на мою страницу aspx

3) Привязать элемент управления DataList к моему источнику SQLDatasource

4) Вставлять, обновлять и удалять, используя мой Datalist или программно, используя встроенные методы SQLDatasource, например,

MySqlDataSource.InsertParameters["author"].DefaultValue = TextBox1.Text;

MySqlDataSource.Insert();

Однако недавно я получил относительно простой веб-проект. Поэтому я решил использовать 3-х уровневую модель ... Но на полпути я устал и просто не стоил этого! Казалось, что я работал слишком тяжело для проекта, который мог бы быть легко реализован парой элементов управления SqlDataSource.

Так почему модель N-уровня лучше моего подхода? Это как-то связано с производительностью? Каковы преимущества элемента управления ObjectDataSource над элементом управления SqlDataSource?

Answer 1

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

При вашем подходе это означает применение шаблона копирования / вставки с одной страницы на другую, чтобы вы могли использовать один и тот же запрос. Теперь подумайте, что произойдет, когда что-то изменится (например, структура БД), и вам придется повторить эти изменения между 50 страницами, на которые встроены литералы SQL - вы попадаете в беду.

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

Answer 2

Вот несколько причин для n-уровня:

1. n-уровень означает лучшую масштабируемость. Вы можете добавить серверы среднего уровня для масштабирования, если сервер базы данных не может идти в ногу.
2. n-ярус позволяет добавить защиту вне базы данных (например, серверы каталогов предприятия).
3. n-уровень предоставляет вам посредника, который может проверять наличие SQL-инъекций, проверять и связывать переменные из пользовательского интерфейса.
4. n-ярус может означать более слабую связь. SqlDataSourceControl означает, что пользовательский интерфейс знает все о схеме базы данных. (Это шатко - если вы добавите новое поле, эффект будет колебаться в интерфейсе независимо от того, что вы делаете.)
5. Средний уровень позволяет другому пользовательскому интерфейсу повторно использовать функциональность.

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

Answer 3

Если вы не строите проекты среднего или крупного размера, вы раскрыли здесь секрет.

n-уровень полезен только для больших приложений; ниже этого, это в лучшем случае практическое упражнение, и, несмотря ни на что, замечательное времяпрепровождение.

Answer 4

На самом деле проблем с использованием элемента управления SqlDataSource нет, если хотите. При этом существует множество веских причин для использования N-уровневой системы.

1. оно тесно связывает вашу презентацию слой к вашему слою данных
2. Вы дублируете тонну работы
3. SqlDataSource запросы часто уникальный

Answer 5

Я обнаружил, что когда вы впервые начинаете создавать прототипы своего приложения, гораздо быстрее использовать объект SQLDataSource. Используя этот метод, вы можете в первую очередь быстро перейти к разработке веб-приложений. Когда ваше приложение начинает расти и отражает необходимость перехода к использованию веб-службы для связи на уровне яруса базы данных, вы можете принять решение на этом этапе. Некоторые из преимуществ заключаются в создании функционального веб-приложения для демонстрации клиентам. Как только они согласятся с дизайном и подходом, вы можете принять решение, возможно, преобразовать запросы в веб-сервис. Это не очень сложно, так как вы уже создали запросы в SQLBuilder, и вам осталось только установить / переместить эти же запросы из веб-службы, а затем вызвать соответствующие запросы веб-службы из уровня пользовательского интерфейса.

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