Почему я должен использовать Подход N-Tier, Когда использование SqlDatasource НАМНОГО ЛЕГЧЕ?
Когда дело доходит до веб-разработки я всегда пытался работать УМНЫЙ не ТРУДНО. Таким образом для вдоль времени Мой Aproach к взаимодействию с базами данных в моих проектах AspNet был этим:
1) Создайте мои хранимые процедуры
2) Перетащите управление SQLDatasource на моей aspx странице
3) Свяжите Управление DataList с моим SQLDatasource
4) Вставьте, Обновление и Удалите при помощи моего Datalist или программно использования, созданного в методах SQLDatasource, например,
MySqlDataSource.InsertParameters["author"].DefaultValue = TextBox1.Text;
MySqlDataSource.Insert();
Недавно однако я получил относительно легкий веб-проект. Таким образом, я решил использовать 3-уровневую Модель... Но я был исчерпан на полпути и просто не казался стоящим того! Казалось, что я также упорно работал для проекта, который, возможно, был легко выполнен несколькими Средствами управления SqlDataSource.
Итак, почему Модель N-Tier лучше, чем мой Подход? Это имеет что-нибудь, чтобы сделать с производительностью? Каковы преимущества управления ObjectDataSource Управлением SqlDataSource?
4 ответа
Вы подходили к вещам задом наперед. Подход SQLDataSource предназначен для небольших легких проектов. Как только вы станете больше, вы захотите повторно использовать структуры и запросы между множеством разных страниц.
В вашем подходе это означает применение шаблона проектирования копирование / вставка с одной страницы на другую, чтобы вы могли использовать один и тот же запрос. А теперь подумайте, что происходит, когда что-то изменяется (например, структура БД), и вам нужно реплицировать эти изменения между 50 страницами, в которые встроены литералы SQL - вы попали в мир боли.
Здесь на помощь приходит n-уровневая модель - логика доступа к данным должна быть изолирована на отдельном уровне, и должен быть только один фрагмент кода, отвечающий за определенную логику бизнеса / данных, и если там необходимо внести изменения будет только один фрагмент кода, который нужно изменить. Проблема с этим подходом заключается в том, что он требует больше усилий, а окупаемость видна только для достаточно больших проектов.
Вот пара причин для n-уровня:
- n -tier означает лучшую масштабируемость. Вы можете добавить серверы среднего уровня для масштабирования, если сервер базы данных не успевает за ними.
- n-звено позволяет добавлять безопасность за пределами базы данных (например, серверы каталогов предприятия).
- n-уровень дает вам посредника, который может проверять SQL-инъекцию, проверять и связывать переменные из пользовательского интерфейса.
- n-уровень может означать более слабую связь. SqlDataSourceControl означает, что пользовательский интерфейс знает все о схеме базы данных. (Это ненадежно - если вы добавите новое поле, эффект будет отражаться в пользовательском интерфейсе независимо от того, что вы делаете.)
- Средний уровень позволяет другому пользовательскому интерфейсу повторно использовать функциональные возможности.
Если вы просто пишете веб-приложение CRUD без возможности совместного использования и хорошей масштабируемости, ваш подход может подойти.
На самом деле нет никаких проблем с использованием элемента управления SqlDataSource, если вы хотите. При этом существует множество веских причин для использования многоуровневой системы.
- он тесно связывает уровень представления с уровнем данных
- вы дублируете тонну работы
- Запросы SqlDataSource часто уникальны
Если вы не занимаетесь средними или крупными проектами, вы открыли здесь секрет.
n-уровень помогает только для больших приложений; ниже, это в лучшем случае практическое упражнение и, тем не менее, замечательная трата времени.