Отправляет email-рассылки с помощью сервиса Sendsay

Создаем свой бизнес

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Секреты бизнеса. Предприниматели рассказывают..." на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Февраль 2004   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Автор
Людмила Лунькова

Статистика

12.222 подписчиков
-21 за неделю
←   Все выпуски   →

Создаем свою информационную систему


Информационный Канал Subscribe.Ru

Создаем свою информационную систему

Проблема среднего слоя

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

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

  1. пассивное SQL  хранилище
  2. сервер, который реализует логику блокирования, контроля прав и аутентификации пользователей на основе хранимых процедур
  3. классический средний слой, который обеспечивает удобный доступ к данным документов и некоторым сервисным функциям. Например, поиск, создание документов и т.п.
  4. Интерфейсный уровень, который может быть реализован, либо в виде нормального Windows приложения, либо в качестве WEB сервера, который  формирует для пользователя интерфейсные представления.

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

Таким образом, начинаем мы со среднего слоя. Какие конкретно надо будет вызывать хранимые процедуры, и с какими параметрами. Я буду по мере необходимости говорить и кратко пояснять, что эти процедуры делают и как.

Теперь возвращаемся к проблеме. Так собственно, зачем нужен средний слой? Когда я смотрю на разные примеры кода я почему-то прихожу в недоуменье.  Ну посмотрим хотя бы на DataSet, Это что такое? Это просто база данных в памяти – и все. Я совершенно не понимаю зачем нужен такой средний слой, который мне базу из хранилища переносит в память и при этом жизнь моя, как программиста легче не становится совершенно. Даже наоборот. Не говоря уже о том, что  для многопользовательской системы многие подходы просто не применимы, такие как проверка актуальности записи по составу всех полей, например.

Я, как нормальный, ленивый человек, хочу, чтобы, та структура данных, которую я  описываю, или  представляю, оказалась бы мне доступной уже на уровне среднего слоя. Даже не знаю, как это попонятнее объяснить.  Представьте себе что мы захотели создать что-то похожее на Exel с богатой объектной моделью и захотели хранить это дело в базе данных. Так средний слой – это и есть объектная модель, а вовсе не обернутая  в пеленки база данных. В среднем слое есть нормальная иерархия объектов. Если на примере Excel, то Workbook – WorkSheet – Range – Cell. Это совсем не тоже самое, что куча таблиц, даже если они и представляют иерархическую связку. Проблема несоответствия типа хранения в базе данных и  типа в объектной модели остается.

Я бы сформулировал основную задачу среднего слоя так: дешифровка реляционного способа хранения информации для представления ее в виде иерархической модели.

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

Пример. Есть поле в базе данных, которое хранит номер месяца.  Я знаю, что это не просто число, потому что у меня есть метамодель – специализированное хранилище информации о структуре всех объектов системы.  Использовать данные метамодели в режиме исполнения можно, но не интересно, так как резко снижает производительность системы. Эту информацию очень правильно использовать в специальном приложении, которое формирует исходный код второго слоя.  Причем код такой, что данные из метамодели «вшиваются» в этот код. Это уж точно на производительность повлиять не может.

Но вопрос сейчас в другом. Вопрос в том, что мы уже знаем, как трактовать эти числа, чтобы пользователь получил в итоге нормальное представление.

Поэтому поле должно превратиться не просто в число, а в нечто более сложное. Например, специальный объект с как минимум тремя методами:

SetValue

GetValue

ToString

На самом деле нужен бы еще и метод, для формирования списка возможных значений, тогда это будет уже совсем «правильный» средний слой.

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

Проблема не простая, но имеет очень красивое и простое решение, даже несколько, хотя не все красивыеJ

Раз есть проблема – будем решать.

Попробуем построить полную формулировку. Мы работаем с большим количеством типов документов, каждый из которых (тип) представляет собой изолированный сегмент базы данных. Здесь «изолированный» означает, что если в базе данных есть таблица, которая относится к хранению данных документов, то эта таблица может принадлежать только документам одного типа. Тип документа строится из иерархически организованных разделов, каждый раздел соответствует одной таблице в базе данных. Поля раздела могут быть скалярными, или ссылочными. Ссылочные поля могут указывать либо на документ в целом (есть специализированная таблица пар идентификатор+ тип документа), либо на строку раздела абсолютно любого документа.

Задача состоит в том, чтобы превращение информации в базе данных в объект (сам документ, либо объект-строка раздела) было совершенно прозрачным для пользователя и он мог работать с системой совершенно не задумываясь о структуре базы данных.

Выпуск получается, каким-то длинноватым… поэтому, само решение мы обсудим в следующий раз.

Ведущий рассылки: Михаил М. Баранов
bami@murometz.spb.ru www.murometz.spb.ru Кубики для взрослых
http://subscribe.ru/
E-mail: ask@subscribe.ru 		Отписаться
Убрать рекламу
В избранное