фиганычАлексей К,

нет - пул есть, просто все пользователи работают под одним пользователем БД - не требуется создавать каждого нового пользователя как пользователя в БД, назначать ему права и прочее, однако требуется создание внутренней организации доступа.
Внутренняя организация доступа - мембершип. Всё уже придумано за нас. Берем его любую модификацию в зависимости от провайдера и юзаем на здоровье. Таблички нативные автогенеренные.

фиганычМСУПравильно, только так и никак иначе. Вырисовываются явные плюсы веба - он по дефолту трехзвенен. А толстый юай трехзвенить дорого и долго. Но надо, если на то пошло.

С WCF не долго и не дорого - считай тот же веб (если во внутря смотреть), и для monkey считай ничего не меняется - для получения данных не нужно дёргать всякие sql-connection, query и прочая - а просто дёргаешь процедуру - получаешь дата-сет - чистишь кожуру и жуешь.
С вцф всё намного проще - шикарные возможности для аутентификации с авторизацией, веб-сервисы asmx курят в сторонке. Но так или иначе - лишний кодируемый слой, который нужно поддерживать. Веб напрямую через тот же дал обращается к базе, без лишних трудозатрат на транспорт. И тупо отдает отрендеренный гуй через html. Проще, быстрее, универсальнее - любой клиент, от мобилы и планшета.

Алексей КПросто мне XML-ные маппинги не нравятся.
Они плохо пахнут? :) Чем твой говнокод на t4 лучше нативного генератора, в котором - ни строчки кода, всё работает из коробки.

фиганычпросто дёргаешь процедуру - получаешь дата-сет - чистишь кожуру и жуешь.
Батенька, за трансфер датасетов через SOA - яйца под нож!

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

Cat2МСУ. Если опять не начнешь матом ругаться на оппонентов и оскорблять их другими способами, то эта дискуссия не будет закрыта раньше времени и будет плодотворна.
Покажешь хоть одну ссылку на то, где я оппонентов матом крыл?

Cat2Алексей КСтрогая типизация + LINQ удобнее чем SQL.
Поскольку типизация не объемлет все возможные запросы, например, сборку текста запроса внутри хранимой процедуры, то ее нельзя использовать везде
Особенные запросы (CTE и пр. замороченные лохмотья), с которыми ORM не умеет работать (либо работает хуже) - пиши на хранимых процедурах, которые точно так же обвязываются через тизированный контекст. Все остальные 99% - на чистом ORM. Какие сложности?

Cat2МСУСамая вменяемая масштабируемая архитектура безопасности - роли с правами хранятся в таблицах
Как и делается по умолчанию в СУБД. "Все данные о базе хранятся в таблицах самой базы". Правило Коддта.
Ты не понял. Я о том, что реализовывать секурность средствами сиквельных пользователей и ролей, либо еще хуже - через сиквельную виндовую аутентификацию с теми же сиквельными ролями - зло. То же самое относится и к остальным СУБД.

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В связи с этим просьба к модераторам.
Чистите оскорбления, а не закрывайте топик
Хватит сцать раньше времени. И не зуди, надоел.

Cat2МСУЯ о том, что реализовывать секурность средствами сиквельных пользователей и ролей, либо еще хуже - через сиквельную виндовую аутентификацию с теми же сиквельными ролями - зло. То же самое относится и к остальным СУБД.
Поясни конкретнее, почему это с твоей точки зрения зло.
Выше объяснил про масштабируемость, модульную архитектуру (доступность) и гибкость. Это очень важные компоненты архитектуры.

Cat2МСУВсе остальные 99% - на чистом ORM. Какие сложности?
В том, что таких запросов 99%. Какой смысл использовать ОРМ для одного процента?
Выбрось свою организацию хранилища на помойку и уволь архитектора схемы. Поможет, уверяю. Работа с БД должна быть как можно прозрачна. Актуальные боевые данные - отдельно, BI - в кубах через ETL отдельно. Никаких сложностей. То о чем ты пишешь - не поддается здравому осмыслению.

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