ViPRosМСУ,

ну, вот что получается при попытке лишить клиента возможности генерировать динамический запрос к БД путем делегирования этих вещей фасаду в виде WCF уровня.
1. Выигрыш - ну да, клиенту больше не надо иметь коннекшн стринг к БД, токо логин и пароль для мидла

1. Удобство поддержки. Уровни не зависят друг от друга, что позволяет выполнять обновления или изменения, не оказывая влияния на приложение в целом.
2. Масштабируемость. Уровни организовываются на основании развертывания слоев, поэтому масштабировать приложение довольно просто.
3. Гибкость. Управление и масштабирование каждого уровня может выполняться независимо, что обеспечивает повышение гибкости.
4. Доступность. Приложения могут использовать модульную архитектуру, которая позволяет использовать

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

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

ViPRosМСУ, ну успокойся с очевидными вещами то
цена вопроса высока
Ок. Просто эти вещи не для всех очевидны, оказывается.

Ну а по поводу метаданных всё точно так же, как в твоем случае, только добавляется один уровень, который и будет транслировать заранее определенные запросы клиентов (xml, dataset для динамики) в SQL, снимать результат и готовить пакет ответа.

ViPRosМСУ,

ну вот как токо появляется среднее звено, так черт дергает там же и данные кешировать для всех клиентов:)
а это очень сложно
а без этого получается просто прокси
Да как не назови, оно очень удобно и масштабируемо :) Кстати, коль ты затронул вопрос кеширования, то в wcf он уже реализован , очень гибкий и мощный инструмент.

sphinx_mvЗа своими дешевыми вбросами следи, "шпециалист"!
Но вернемся к первоисточнику :
Layered Application mostly concerns managing design dependencies between components, while Tiered Distribution concerns optimizing the runtime server configuration to meet system-level operational requirements. Therefore, the criteria for structuring your application into layers are fundamentally different from the criteria used for optimizing physical component deployment. For example, one of the driving forces for assigning components to layers is to minimize the dependencies between components in different layers. Conversely, a primary driver for optimizing component deployment is to match a component's resource consumption profile to an appropriate server. This implies that a direct mapping of layers to tiers is often not the best distribution strategy. For instance , the Open Systems Interconnection ( OSI ) network protocol stack reference model is structured into seven layers. Seven different servers, each hosting a separate layer, are not required or even recommended.
OSI - это все 3 (три!) знакомые буквы, которые Вы нашли во всей цитате?! А Вы "заметили", что OSI была приведена в качестве ПРИМЕРА?
А, ну, да... Наши горе-орхетектары не в курсе, как перевести "for instance"... Ну, хоть бы автопереводчиком воспользовались, что ли - здесь или здесь ... И в каком заборостроительном институте учат таких "орхетекторов"?!
Очередные полупьяные потуги что-то понять в архитектуре из доков от шизоидного саппортера первой линии поддержки? Ну что ж, давай разбираться в буквах
Что тебе не понравилось в OSI? То, что он реализован на 7 уровнях и твое больное воображение не может понять, насколько это много? Так я и не сомневался. Ты хотя бы до конца манускрипт дочитал, бестолочь.

SolutionBased on these requirements and constraints, the application architects define a set of components as specified in Three-Layered Services Application, and the system architects define a set of tiers as specified in Tiered Distribution. The discussion between the two parties while performing this mapping often causes significant changes to the components and tiers as each party becomes aware of the other's perspective.

You start the meeting by mapping the component roles defined in Three-Layered Services Application to tiers, using the forces described earlier as a guide. For example, user interface components may be mapped to the Web tier, whereas business components are almost always mapped to the application tier.

Several common deployment plan models for enterprise applications have been identified, based on Three-Layered Services Application: simple Web application, complex Web application, extended enterprise application, and smart client application.


В статье даются рекомендации, как архитекторам планировать трехуровневую архитектуру на различных вариациях. Сходи в сад и подучи английский язык

sphinx_mv"Тысячи лемингов не могут ошибаться" (с) Ага...
С Вашими "познаниями" в развертывании приложений только Вам и осталось выступать в качестве "икспэрта"...

Ну, и про "дешево" - это Вы опять в своем букваре не смогли буквы сложить:
Each additional tier to which components must be deployed adds complexity, deployment effort, and cost. Deploying all components to one tier is relatively simple. [skip] Finally, each additional tier adds fixed and recurring costs for the additional hardware composing the tier. Что в переводе для безграмотных орхетектаров означает: каждый дополнительный уровень на котором должны быть развернуты компоненты добавляет сложности, усилий на развертывание, обслуживание и сопровождение (да, немножко отсебятины) и стоимость . И каждый дополнительный уровень добавляет фиксированные и текущие расходы на дополнительное оборудование, составляющее этот уровень.
"Бабушка надвое сказала" (с) Точно.
Твои ковыряния в архитектурых гайдах приводят к неизбежному желанию откровенно поржать с твоих пенок, "специалыст первого уровня паддержъки". Ага
Тупица, я тебе это и говорил, что каждый уровень нужно поддерживать и мониторить его работу, но "стоимость" этой работы практически никакая, потому что-то это прикладной уровень, а не какой-то там внешний от какого-то там стороннего поставщика, который находится за 7 морей. Включи остатки головного мозга и пошевели ими уже, наконец. Про расходы на дополнительное оборудование - это риторический вопрос. Если идет речь о корпоративном софте и высоких требованиях по отклику и безопасности, то выделить отбалансированную апп ферму из парочки серверов - плевое дело. Да и не твоё соплячье это дело, поддерженец, откуда айти директор возьмет бюджет, чтобы поднять апп сервер

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

sphinx_mvА орхетектары-теоретеги могут хотя бы приблизительно оценить аппаратные затраты на развертывание системы?
Какак средняя нагрузка на отдельный сервер при двойном резервировании считается высокой и уже нужно думать о добавлении нового? А при трехкратном резервировании? И что получилось в "итого" для каждого уровня? А для всего разверывания "в-целом"?
Терзают смутные сомнения, что вряд ли - в заборосторительных институтах этому не учат...
Чтобы получить требуемые данные пиковой и рабочих нагрузок, необходимо это смоделировать. Как писать нагрузочные тесты в VS, ты не поймешь, поэтому не буду заострять на этом внимание. Про установка Load Test Results Repository тоже умолчу, так как окончательно уничтожу твои искометные познания в пух и прах Но чтобы окончательно пошевелить палочкой твое скудоумие, могу пнуть сюда в этот рецепт . Далее. Есть сетевые инструменты для имитации трафика, при включенном анализаторе всех нодах серверов под балансировщиком. Там можно узнать о порогах обработки рекевстов, узнать о провалах, о порогах отказа, посмотреть прочую статистику. Как вариант, Nsauditor Network Security Auditor, бестолочь.

sphinx_mvСвой букварь Вы уже вытащили оттуда, куда Вам его засунули?
И, кстати, читать-то его Вы так и не научились - даже по буквам...
Ты еле извилинами ворочаешь и плаваешь, как гумно в проруби - о каких еще буквах речь, "процеДУРник"?

sphinx_mvВы бы чем про наносекунды петь, просто взяли бы и померяли латентность в Вашей локальной сети при доступе с Вашего компьютера к серверу приложений... "Орхитектары" должны знать, как это делается - подсказывать не буду.
Вместо измерений локальной сети, почитал бы про возможности WCF в качестве сервера приложений и выбрал бы песочницу для хостинга. С линейкой потом походишь по предприятию

sphinx_mvА еще помнится, некий МСУ с пеной доказывал, что трехзвенка "быстрее", чем двузвенка... Пруфов ему каких-то хотелось...
Ну, "читайте со словарем", если английского не знаете:
Every process and server boundary that a component invocation crosses adversely affects response time. Component invocations that cross process boundaries are several times slower than in-process invocations, while component invocations that cross the network are an order of magnitude slower than component invocations in the same process.
Если и словарем пользоваться не умеете, в общих словах: время отклика любого вызова, пересекающего границы процесса в несколько раз больше больше, чем для вызовов внутри процесса. Время отклика длы вызовов, выполняемых через через сеть - замедление на порядки. И так - для КАЖДОГО дополнительного уровня! Трехзвенка МЕДЛЕННЕЕ, потому что имеет минимум на один уровень больше, по сравнению с двузвенкой - это на всякий случай: вдруг Вы еще и считать не научились.
Самое "печальное" для производительности это то, что взаимодействие между компонентами на разных уровнях практически всегда выполняется через сеть.
Глупенький, читай букварь:

http://msdn.microsoft.com/en-us/library/ms733769.aspx When to Use the TCP Transport
TCP is a connection-based, stream-oriented delivery service with end-to-end error detection and correction. Connection-based means that a communication session between hosts is established before exchanging data. A host is any device on a TCP/IP network identified by a logical IP address.
TCP provides reliable data delivery and ease of use. Specifically, TCP notifies the sender of packet delivery, guarantees that packets are delivered in the same order in which they are sent, retransmits lost packets, and ensures that data packets are not duplicated. Note that this reliable delivery applies between two TCP/IP nodes, and is not the same thing as WS-ReliableMessaging, which applies between endpoints, no matter how many intermediate nodes they may include.
The WCF TCP transport is optimized for the scenario where both ends of the communication are using WCF. This binding is the fastest WCF binding for scenarios that involve communicating between different machines. The message exchanges use the BinaryMessageEncodingBindingElement for optimized message transfer. TCP provides duplex communication and so can be used to implement duplex contracts, even if the client is behind network address translation (NAT).


LatencyLatency is the minimum amount of time required to complete an exchange of messages. All network operations have more or less latency depending on the choice of transport. Using duplex or one-way communication with a transport whose native message exchange pattern is request-reply, such as HTTP, can cause additional latency due to the forced correlation of messages. In this situation, consider using a transport whose native message exchange pattern is duplex, such as TCP.


Бенчмарки тут: http://msdn.microsoft.com/en-us/library/bb310550.aspx



sphinx_mvТакже напоминаю Вам, что Вы распинались о большую безопасность серверов приложений...
Ну, что ж, По причине того, что Вы выучили только 3 (три!) буквы (и буквы эти OSI), и к безопасности они никакого отношения не имеют
Ты забыл, как ты обделался с транзакциями с хранимыми процедурами? Напомнить? У трехзвенки б о льшая безопасность, это доказано и сформулировано во всех манах, начиная от википедии, кончая архитектурными гайдами и доками. И что тебя так обрадовало в OSI, маленький?

sphinx_mvкаждый дополнительный уровень повышает угрозу общему уровню безопасности. Каждый дополнительный уровень добавляет новые серверы и другие объекты инфраструктуры, которые должны быть защищены.
В переводе для "орхетектаров" это означает, что трехзвенная архитектура менее безопасна, чем двухзвенная - сугубо по причине наличия как минимум еще одного дополнительного уровня.
Ты сравниваешь теплое с мягким. Повышение угрозы уровня безопасности на каждом новом уровне незначительно, т.к. находится за натом, за серверами, за фоерволами, за админами, в демилитаризованной зоне при необходимости, и так далее. В случае же двухзвенки основной уровень (связь с СУБД) прозрачно открыт для атаки и может элементарно перехватываться. Безопасность в n-звеньях на порядки выше, чем безопасность в 2 звеньях Это даже детвора знает. Твое рассуждение просто безумно. С каждый новым уровнем безопасность хуже, с этим никто не спорит (для 3 tier, 4 tier, 5 tier, и т.д.). Но это не относится к двухзвенке, т.к. в ней безопасность вообще никакая. И годится это только для лапидарных систем для автоматизации ларьков с сигаретами.

sphinx_mvНе зря я писал, что Вы умеете только ссылаться на документацию, но саму документацию Вы никогда не читаете. И цитаты из того самого документа, на который Вы ссылаетесь ОЧЕНЬ наглядно показывают, какие сказки Вы умеете рассказывать - при чем полностью противоречащие написанному в руководствах...
Не зря я писал, что ты бестолочь и из тебя ничего толкового не выйдет. Пока будешь мыслить процедурно, лучший твой друг - это кирпичная стена.

PichДа! И хотелось бы конечно получить если не подтверждение того, что МСУ читает (или открывает) руководство Microsoft по архитектуре
Enterprise Solution Patterns Using Microsoft .NET, а просто уважительное отношение к разработчикам, которые читают не застарелые документы 10-летней давности, а современные руководства по проектированию приложений.
МСУ! Не читай больше только это пособие http://msdn.microsoft.com/en-us/library/ff647095.aspx. С 2003 года NET изменилась неузнаваемо. Ведь библиотека 2003 года уже совсем не то, что надо использовать сейчас. (The latest version of Enterprise Library (version 6) was released in April 2013)
Читайте вот это http://apparchguide.ms/Book или вот это http://msdn.microsoft.com/en-us/library/dd673617.aspx.
МУС! Прислушайтесь, наконец-то, к советам мудрых товарищей и не дерзите всем подряд.
Присаживайся, двойка.

Microsoft Application Architecture Guide, 2nd Edition , October 2009

P.S. Не позорился бы так, "советчик".

PichМСУ! Кстати, Хотелось бы Вас попросить, правильно применять термины и определения. Если ВЫ можете читать руководство только на руссском языке, то напомню Вам, что используются термины УРОВЕНЬ-tier, или СЛОЙ-lyer. Они, как бы Вам сказать, ну уж совсем не ЗВЕНО, термин, который Вы употребили.
Pich, какие именно термины вводят тебя в ступор? Я тебе уже десять раз сказал, что tier - это уровень (звено), layer - слой. Что тебе еще нужно дополнить? Я тебе даже ссылку давал:
http://translate.google.ru/?tab=wT#ru/en/трехзвенная трехзвенная архитектура = three-tier architecture

Ты там это, выдыхай уже.

PichПонятия слой (layer) и уровень (tier) очень близки, слой используется для логического разделения, а уровень для физического разворачивания.
Хренасе близость...

PichВ руководстве есть разделы, посвященные Проектирование МНОГО-СЛОЙНЫХ !!! приложений и много-УРОВНЕВЫХ приложений.
Будьте добры, ну хотя бы грамотно использовать термины. Чтобы Вас можно было понять, ОБ ЧЕМ ВЫ вещаете тут.
Короче, не ипи мне моск. Если будет что-то по делу, милости прошу. Иначе в сад.