Почему я должен использовать N-уровневый подход, когда использование SqlDatasource намного проще?

когда дело доходит до веб-разработки, я всегда старался работать умно не трудно. Поэтому на протяжении долгого времени мой подход к взаимодействию с базами данных в моих проектах AspNet был таким:

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

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

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

4) вставка, обновление и удаление с помощью моего Datalist или программно с помощью встроенных методов SQLDatasource е.г

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

MySqlDataSource.Insert();

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

Итак, почему модель N-уровня лучше, чем мой подход? Это как-то связано с выступлением? Каковы преимущества управления ObjectDataSource над Элемент Управления Sqldatasource?

6
asp.net n-tier

5 ответов

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

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

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

8

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

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

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

3

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

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

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

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

1

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

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

0