МСУCat2Масштабируемость? Чем она выше, чем в двузвенке?
Да, масштабируемость. Вот чем выше:

Руководство MICROSOFT по проектированию архитектуры приложенийХарактеристиками N-уровневой архитектуры приложения являются функциональная декомпозиция приложения, сервисные компоненты и их распределенное развертывание, что обеспечивает повышенную масштабируемость, доступность, управляемость и эффективность использования ресурсов. Каждый уровень абсолютно независим от всех остальных, кроме тех, с которыми он непосредственно соседствует. N-ному уровню требуется лишь знать, как обрабатывать запрос от n+1 уровня, как передавать этот запрос на n-1 уровень (если таковой имеется), и как обрабатывать результаты запроса. Для обеспечения лучшей масштабируемости связь между уровнями обычно асинхронная.

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

Cat2Она зависит от от возможностей СУБД, а не от способа доступа. И среднее звено ее может только понизить.
Она не зависит от возможностей СУБД, не говори глупости. Возможности СУБД идут лесом, т.к. вменяемые архитекторы в БД видят только тупое хранилище данных, не более того. Главный вопрос опять же в масштабируемости - отмасштабировать приложение на порядки проще, если оно не прибито гвоздями к конкретной СУБД.

Cat2Высокая безопаснеость? В чем она выше, чем при двузвенке?
Да, высокая безопасность. Вот чем:

Руководство MICROSOFT по проектированию архитектуры приложенийПримером N-уровневого/3-уровневого архитектурного стиля может служить типовое финансовое Веб-приложение с высокими требованиями к безопасности. Бизнес-слой в этом случае должен быть развернут за межсетевым экраном, из-за чего приходится развертывать слой представления на отдельном сервере в пограничной сети. Другой пример – типовой насыщенный клиент, в котором слой представления развернут на клиентских компьютерах, а бизнес-слой и слой доступа к данным развернуты на одном или более серверных уровнях.

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

Руководство MICROSOFT по проектированию архитектуры приложенийОсновными преимуществами N-уровневого/3-уровневого архитектурного стиля являются:

Удобство поддержки. Уровни не зависят друг от друга, что позволяет выполнять обновления или изменения, не оказывая влияния на приложение в целом.

Масштабируемость. Уровни организовываются на основании развертывания слоев, поэтому масштабировать приложение довольно просто.

Гибкость. Управление и масштабирование каждого уровня может выполняться независимо, что обеспечивает повышение гибкости.

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


Руководство MICROSOFT по проектированию архитектуры приложенийРассмотрите возможность применения N-уровневой или 3-уровневой архитектуры, если требования по обработке уровней приложения отличаются настолько сильно, что может возникнуть перекос в распределении ресурсов, или существенно разнятся требования по безопасности уровней. Например, конфиденциальные данные не должны храниться на уровне представления, но могут размещаться на бизнес-уровне или уровне данных. N-уровневая или 3-уровневая архитектура также подойдет в случае, если требуется обеспечить возможность совместного использования бизнес-логики разными приложениями и имеется достаточное количество оборудования для выделения необходимого числа серверов для каждого уровня.

Руководство MICROSOFT по проектированию архитектуры приложенийИспользуйте только три уровня, если создаете приложение для внутренней сети организации, где все серверы будут располагаться в закрытой сети; или Интернет-приложение, требования по безопасности которого не запрещают развертывание бизнес-логики на Веб-сервере или сервере приложений. Рассмотрите возможность применения более трех уровней, если соответственно требованиям по безопасности бизнес-логика не может быть развернута в пограничной сети, или если приложение интенсивно использует ресурсы, и для разгрузки сервера необходимо перенести эту функциональность на другой сервер.

Cat2Ну, матом не крыл, но "идиотами" или неким подобным обзывал
Это же просьба относится ка Алексею К.
Ты чё-то гонишь, Кот. У меня с Лёней самые теплые отношения.

Cat2Бывалоча начнется дискуссия, я бы еще чего мог сказть - ан нет. МСУ и Алексей поцапались и тему закрыли.
Кот, ты чего куришь? Алексей - зубр форума, коих единицы. Чтобы я с ним где-то поцапался, ты должен стать балериной. Опять ты не в кассу постишь - то матом я крою, то с Лёней цапаюсь. Пестец какой-то :)

Cat2В связи с этим просьба к модераторам.
Чистите оскорбления, а не закрывайте топик
Хватит сцать раньше времени. И не зуди, надоел.

Microsoft сподобилась перевести на русский незамысловатую писульку "Архитектура приложений для чайников" и Муся резко стал архитектором.

МСУCat2Надежность трехзвенки не может быть выше надежности базы данных. Она обязательно будет ниже, так как включается ненадежность промежуточного звенеа.
На пальцах еще раз: в двухзвенной архитектуре пользователь ПО может безпрепятственно получить строку соединения к БД (пусть даже если ты строишь ПО с помощью виндовой аутентификации в БД). Ты считаешь нормальной практикой, если юзеры (пусть даже особо продвинутые или не очень) начнут хаотично юзать БД через сторонние клиенты (Excel, Access, Management Studio и пр.), делать большие выборки, ковыряться во внутрях БД и искать узкие места? Уже сам факт возможности попадания пользователя в БД, тем более сторонними средствами - вопиющ и опасен. Я уже не говорю про двухзвенки, в которых строка соединения к БД идет от sa либо от достаточно привилегированной сиквельной учетной записи - за такое вообще расстрел на месте.
Cat2, что не понятно по безопасности? Вопросы, комментарии, замечания приветствуются.

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