Неэффективна 3 (физической) архитектуры уровня?
Примечание: Когда я отношусь для разделения на уровни, я имею в виду физический уровень. Многие вопросы на этом сайте, касающемся "уровней", относятся к логическим слоям, который не является тем, о чем я спрашиваю.
Я разрабатываю приложение с помощью стандарта "3 слоя" архитектура, с презентацией, бизнес-логика (BLL) и уровни (DAL) доступа к данным. Технология является WPF, C#, LINQ и SQL Server 2008. Мой вопрос касается физической архитектуры этого приложения.
Я могу поместить BLL/DAL в стандартный DLL, который загружается и работается пользовательская машина, делая 2 архитектуры уровня - клиентская машина и сервер базы данных. Но не слишком трудно превратить BLL/DAL на службу WCF, которая находится на сервере приложений и названа от пользовательской машины. Это дало бы мне 3 архитектуры уровня - клиентская машина, сервер приложений и сервер базы данных.
Мой вопрос - это - что преимуществом использования является 3 архитектуры уровня? Мне часто говорили, что 3 уровня добавляют масштабируемость, но для меня не сразу очевидно, почему это было бы. И конечно Вы собираетесь получить удар производительности с теми же данными, имеющими необходимость сделать два транзитных участка по проводу - с сервера базы данных на сервер приложений, затем с сервера приложений на клиентскую машину.
Я ценил бы совет опытных архитекторов и разработчиков там.
5 ответов
Это зависит от использования вашего приложения и ваших требований к безопасности. Если ваше приложение используется через Интернет и вы храните все, что потенциально является конфиденциальным, настоятельно рекомендуется добавить физическое удаление для базы данных. Никогда и никогда не позволяйте никому извне на машину с прямым доступом к вашей базе данных. Люди могут и будут пытаться взломать вашу систему безопасности только по той причине, что им нечего делать лучше.
Масштабируемость также может иметь значение как перед уровнем представления (перед веб-серверами), так и в базе данных. Размещение балансировщика нагрузки перед уровнем представления позволяет направлять входящие запросы на массив машин, которыми можно управлять независимо. Машины могут быть добавлены в пул в случае необходимости и сняты для обслуживания. Размещение балансировщиков нагрузки между другими уровнями может иметь такое же влияние. Идея состоит в том, чтобы предоставить гибкую, динамическую серверную среду, которую можно настраивать по мере необходимости.
Может быть. Это зависит от того, что и как было реализовано.
Движущей силой создания трехуровневой физической архитектуры не обязательно является производительность.
Причина масштабируемости приведена в том, что сервис может работать на серверной ферме, но клиенты об этом не знают. Размеры фермы серверов могут быть увеличены для удовлетворения спроса, если архитектура была спроектирована для ее поддержки
.] Всякий раз, когда вы задаете вопрос "Неэффективен ли Х?", вы должны немедленно задать себе три вопроса-предшественника: [
]. [- ]
[
- ] [
] Какой ресурс, по Вашему мнению, "неэффективный" должен использоваться эффективно, а может и не использоваться? Время? Пространство? Полоса пропускания? []Development hours?[][
][ ]
[ - ] [
] Почему тебя это волнует? Нет, серьезно: Если ты собираешься потратить хоть минуту на ответ на этот вопрос, должна быть причина. Что это за причина? [
] [ ]
[ - ] [
] По сравнению с чем? [
] [ ]
[
] Что касается вашего комментария о масштабируемости: Некоторое время я, к сожалению, нес ответственность за обслуживание системы, архитектор которой, как было сказано, минимизация обхода базы данных сделает приложение масштабируемым. Он воспользовался этим пониманием и побежал с ним. Вы можете прочитать об этом проекте [] здесь []. Мне пришло в голову, что я должен был упомянуть о том, что ни разу за все десятилетие существования этого приложения в него не входили одновременно более четырех пользователей[
].] Основным преимуществом 3t приложений, описанных так же, как и вы, является не масштабируемость. Возможно, обслуживаемость [
]. [] Для того, чтобы сделать вашу архитектуру масштабируемой, вам нужна еще одна технология, о которой вы не упоминали. - вам нужны услуги. Я бы предложил WCF. [
] []Создание службы BLL WCF (или нескольких служб) сделает ваше приложение более эффективным и масштабируемым, что позволит работать с BLL на различных/многочисленных машинах.[
].Неэффективность в глазах смотрящего.
Например, наличие всего, что происходит на клиенте, может увеличить объем памяти или требования к ЦП / сети клиентских компьютеров. Если эту работу можно переложить на серверную / серверную ферму, вы можете сэкономить на обновлении оборудования клиентских ПК только для запуска вашего программного обеспечения. Если требуются дополнительные ресурсы или обновления, их можно добавить / выполнить на уровне бизнес-логики, не затрагивая клиентов.
Кроме того, наличие бизнес-логики на отдельном уровне может быть более эффективным позже (с точки зрения разработки программного обеспечения), когда вам потребуется раскрыть некоторые функции вашего приложения в веб-системе, надстройке Outlook или приложение для iPhone. Вам не нужно обновлять все эти системы при незначительном изменении бизнес-логики.
Безопасность может быть лучше, поскольку вашим пользователям не нужен прямой доступ к серверу базы данных, они изолированы сервером приложений.
Это также заставляет вас думать о своем приложении в модульном стиле с четко определенными интерфейсами, которые могут иметь архитектурные преимущества для дизайна вашего приложения.