2/3-х уровневая архитектура: как понимать? Чем может помочь MS MTS?

> Читал я про 2,3 уровневую реализацию, но как осуществить реально - не очень понимаю.
> 2-х уровневая - это клиент-серверная?

Ну да, где вся функциональность разнесена на две составляющих:

• база(ы) данных
• клиенты этой(их) баз данных

причём каждый из них занимается "своим делом":

• база данных, с классическим набором в ней средств, обеспечивает: хранение, доступ, контроль целостности, контроль корректности значений, транзакционность групповых изменений, резервное копирование, и т.д. и т.п.
• средствами клиентов, обеспечивается работа с проекциями данных из БД на их задачи.

Проблемы:

Если несколько однотипных клиентов (а такое всегда есть :-), то что делать? Хотелось бы логику их типичной работы с данными как-то "централизовать" (т.е. "нормализовать" код :-). Возможны два решения:

• выделять это всё в хранимые процедуры сервера (однако, хочу заметить, что писать обработку данных на T-SQL не для слабых :-) в случае если БД будет SQL Srver, конечно). К тому же, если эта логика подвержена частым изменениям, придётся и часто "тревожить" базу данных, внося изменения, которые к данным, как таковым, отношения не имеют.
• прописывать в код на клиенте (однако это уже "денормализация" :-( и этого следует всячески избегать :-). Как достаточно элегантное решение на этом пути, казалось бы, VFP позволяет использовать Фоксову базу данных для этих целей, обеспечивая "однозадачных" пользователей как необходимыми им данными, так и логикой работы с ними... Однако, это опять приводит к определённому множеству, хоть и более мелких проблем :-) В частности:
  • дублирования всё равно не избежать, поскольку разным группам пользователей всё равно потребуется нечто общее как по данным, так и по их обработки.
  • трудно надёжно обеспечить транзакционность групповых изменений
  • и т.п.

По этому первый случай, всё-таки как-бы более разумный, однако, при этом "очень толстым" (многофункционально специализированным) становится сам сервер БД, к тому же подверженный частым изменениям... короче, со всеми вытекающими отсюда последствиями.

> 3-х уровневая, как я понимаю, использует еще посредником и COM объекты?

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

• "нормализовать" (т.е. исключить какое-нибудь дублирование на клиентах)
• обеспечить к нему доступ всех в нём нуждающихся (и естественно в сетевом варианте)
• сделать это прозрачным образом, в смысле изменения месторасположения в сети
• обеспечить средствами работы с источниками данных (поскольку именно этот код и производит основную и интенсивную работу с данными, то имеется желание иметь некую общую функциональность, обеспечивающую оптимизацию по доступу к данным и работы с ними)

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

... И далее, поскольку под Windows технология создания такого рода программного обеспечения это безусловно COM (вернее DCOM), то конечно же речь идёт о том, что средний слой придётся оформлять (хотим мы этого или не хотим) в виде COM-компонент.

> В связи с этим возникает вопрос.
> Надо будет сделать права доступа на различные функции в программе.
> Т.е. необходимо будет закрыть любой доступ к БД,
> вплоть до закрытия чтения, минуя программу. Как это реализовать?

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

> Как я понимаю надо писать COM объекты серверного типа,
> и чтобы только они имели доступ к базе данных,
> а чтобы используя ODBC и любую другую программу,
> нельзя было даже отрыть любую таблицу БД.
> Но это возможно только для клиент-серверной версии. Я прав?

В идеале, да! Но вот конкретно с использованием VFP в качестве инструмента для созданием клиентов есть немалое НО. Пробую объяснить. Дело в том, что в том виде как есть, у VFP ODBC-ориентированный доступ к внешним данным, и все его средства настолько специализированы на этом, что что-либо другое (например ADO) вызовет значительное повышение трудоёмкости написания клиентов (сравнимое даже с VB :-), по этому в настоящий момент, скорее всего, если речь идёт именно о клиентских рабочих местах написанных на VFP, потребуется применить некое "половинчатое" решение :-( ... И по моим личным представлением, выглядит оно так:

• все действия с данными, грубо говоря, типа: удалить, изменить, добавить, - безусловно, должны осушествлять компоненты среднего слоя, взаимодействуя с клиентами только лишь через посредство своих COM-интерфейсов
• всё что касается получения данных с целью их отображения на клиентах, ради уменьшения трудоёмкости, увы, придётся получать непосредственно с серверов БД через ODBC, как источников данных, непосредственно зарегистрированных в ODBC Administrator на клиентах. Другими словами, как совершенно традиционный способ работы с удалёнными данными из VFP. [Однако, если есть желание побороться за "чистоту идей", можно конечно перейти полностью или частично на ADO или массивы в памяти, ссылки на которые получать непосредственно от компонент среднего слоя, тем самым полностью исключив непосредственную связь клиентов с БД сервера данных. (Нужно сказать, что имеется VFPCOM-утилита на http://msdn.microsoft.com/vfoxpro/downloads/updates.asp, позволяющая выполнять преобразования: VFP.cursor<-><->ADODB.Recordset)]

> Ранее Вы упомянули MTS, как встроенный в OS MS Win2000.
> Простите, MTS - это Microsoft Transaction Server? Просто с 2000 не работал пока :(

И я тоже :-(. Однако, это так. И я, сам того не замечая, почти полностью расписал функциональные возможности MS Microsoft Transaction Server (MTS) (в OS MS Win2000 входит как Component Exlorer), всё вышеперечисленное он автоматически обеспечивает. Кроме того, если коротко, то на мой взгляд имеется нечто достаточно важное, но не попавшее в обсуждение выше. MTS, являясь средой существования COM-компонент, объединённых в пакеты, обеспечивает:

• создание dll-копонент (не exe), поскольку MTS запускает свой процесс на сервере, к тому же в так называемой модели apartment (т.е. потока защищённой, совершенно не беспокоясь о проблемах меж потоковой синхронизации доступа к компонентам).
• поддержку активными оптимальне количество соединений (Connect) к внешним источникам данных (это очень существенно может увеличить производительность, поскольку время даже одного соединения, как правило, отнимает значительное времени).
• поддержку транзакция не только к одной внешней базе данных (если она конечно их поддерживает), но и к группе БД.
• защита доступа к компонентам может быть организована как ролевая
• ну и т.д.

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

И, конечно же, это всё опять не без проблем:

• MTS 2.0 худо-бедно работает под Windows NT (не под Win9x)
• достаточно требовательный (и прожорливый) по ресурсам
• порой глючит и имеет много "тёмных" пятен, которые из документации не раскопать
• ну и т.п.

Однако, если с ресурсами ему вольготно, он действительно эффективно обеспечивает то, что ему предписано :-)

См. также хоть и устаревшую, но всё же информацию об MTS, применительно к VFP: Microsoft Transaction Server для Разработчиков Visual FoxPro By Randy Brown Microsoft Corporation, Октябрь 1998 [Резюме: Обсуждается использование Microsoft(r) Visual FoxPro(r) версии 6.0 с MTS при разработке прикладных программ трехслойной архитектуры. (36 печатных страниц). Включает код примеров]. на http://msdn.microsoft.com/library/en-us/dnfoxgen/html/mtsvfp.asp?frame=true (eng)

См.
- Building Middle Tier Objects in Visual Foxpro By Jim Booth на http://www.jamesbooth.com/n-tier.htm (eng)
- Introduction to COM+ (Review of n-tier solutions, COM, and MTS) by Craig Berntson на http://http://www.craigberntson.com/Articles/kb011.htm (eng)
- Using Microsoft Transaction Server with VFP By Rick Strahl http://www.west-wind.com/presentations/mts/mts.htm (eng)

На http://www.microsoft.com/com/wpaper/default.asp (eng) имеется обширная информация от Microsoft.

См. также серию примеров кода и сравнения работы VB и VFP под MTS на Web Solutions, точнее на http://members.home.net/bmassi/comtestingseries.htm (eng)

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

По вопросам, связанным с этим веб-узлом, обращайтесь по адресу: © Michael Drozdov, 2000-2005. Все права защищены. Последнее изменение страницы: Вт, 23 августа 2005