Советы по разработке архитектуры веб-приложения ASP.NET

Question

ранее мое веб-приложение ASP.NET подключалось к базе данных напрямую, используя ADO.NET. Теперь я хочу изменить его на 3 уровня: уровень ASP.NET, средний уровень веб-службы и уровень базы данных. Я думаю, что есть преимущество в том, что я мог бы абстрагировать источник данных на передний уровень ASP.NET, слабо связанный и снизить потенциальные риски безопасности, чтобы позволить внешнему веб-приложению ASP.Net иметь прямой доступ к базе данных и т. Д.

По сравнению с двухуровневой архитектурой и трехуровневой архитектурой я столкнулся с двумя основными проблемами.

1. Дополнительный промежуточный уровень веб-службы будет вызывать больше трафика, например ASP.NET не общается с базой данных напрямую, но общается с веб-службой, а веб-служба общается с базой данных, что приведет к увеличению трафика. Это будет узким местом? Любой общий совет, чтобы решить эту проблему, если это узкое место?

2. Поскольку ASP.NET не может подключиться к базе данных, но может подключиться к веб-службе, он не может легко получить объект DataSet / DataTable. Становится трудно представить данные табличной формы элементам управления с привязкой к данным. Любые идеи, чтобы сделать презентационный слой в ASP.NET проще кодирования?

С уважением,
George

Answer 1

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

Есть ли у вас:

• Имеют срочные потребности, связанные с безопасностью, которые требуют отключения веб-интерфейса от сервера базы данных (нет, не гипотетически: «Держу пари, это было бы более безопасно», но очевидные конкретные проблемы безопасности, которые не могут быть решая, умно понимая, какие права БД вы предоставляете вашему приложению ASP.NET)

• Ожидайте полной замены уровня данных в какой-то момент в будущем (возможно, многократно), и, таким образом, необходимо изолировать вашу веб-базу кода от радикальных изменений БД ?

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

Answer 2

Относительно вашего вопроса №2 - вы наверняка можете вернуть DataSet из веб-службы. http://tinyurl.com/ah58xc

Однако, возможно, лучшим вариантом будет просто рефакторинг вашего приложения, а не превращение его в многоуровневый. Например, разделите «доступ к данным» в отдельный проект библиотеки классов, на который вы ссылаетесь из своего проекта ASP.NET. Это может сделать вещи более организованными и, возможно, выполнить то, что вы хотите сделать с помощью многоуровневой архитектуры.

Кстати, самая большая опасность при создании нескольких уровней, когда они могут вам не обязательно понадобиться, заключается в том, что вы в конечном итоге создаете «прокси-код» из-за отсутствия лучшего термина. То есть методы, которые не служат никакой цели, кроме как вызывать «настоящие» внутренние методы с теми же параметрами. Сначала это кажется лучше, потому что у вас чистое разделение слоев, но это приводит к проблемам с обслуживанием в будущем, потому что, например, чтобы добавить параметр в метод, вы должны добавить его 3 раза (бэкэнд, слой прокси и слой представления).

Answer 3

Мой первый вопрос: почему веб-сервис посередине? Если все это будет выполняться на одном физическом компьютере, вы можете реорганизовать средний уровень, который используется через набор интерфейсов и использует прямые вызовы методов.

Я работаю над архитектурой, которая отделена от веб-службы среднего уровня, но она содержит всю критически важную бизнес-логику компании и не будет напрямую представлена ​​в Интернете. Что-то вроде:

{интернет} -> | DMZ | -> Веб-сервер -> | Firewalled LAN | -> Сервер приложений -> Сервер базы данных

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

Если вы собираетесь использовать WCF для связи между серверами, я бы предложил использовать что-то вроде двоичной сериализации через TCP вместо SOAP. Это должно работать лучше (не стесняйтесь настроить быстрый тест). Я сам не пробовал, но WCF мог бы сериализовать набор данных или таблицу по проводам. Смотри здесь .