История такая: собираюсь писать свою платформу для разработки, ищу оптимальный путь к решению этой задачи, хочется выявить все подводные камни ещё на берегу. Поэтому у меня просьба к тем кому интересно и кто в этом разбирается прочитать написанное, посмотреть диаграммы и дать свои комментарии. К диаграммам прошу сильно не придираться - делал на том что было
Занимаюсь разработкой на платформах "SharePoint" и "1С: Платформа 8.1" уже более 6 лет, поэтому хорошо понимаю преимущества подобной разработки. Главное - это скорость разработки, использование коробочных продуктов или их переиспользование с требуемой доработкой . Но недостатков у платформ тоже хватает - начав разработку на платформе, попадаешь в её рамки и чем меньше ограничений у платформы тем проще разработка.
Понятно, что любую задачу можно решить используя .NET или Java. Но хотелось бы иметь под рукой инструмент, который бы упрощал решение задач, избавлял от рутинной работы, предоставлял универсальные готовые функции. И поэтому у меня возникло желание создать свою платформу для автоматизации бизнеса и самой разработки бизнес-приложений. В своей платформе хотелось бы сочетать преимущества платформ "SharePoint" и "1С" и по возможности избежать их недостатков.
Начну с описания видимых мной преимуществ и недостатков платформ SharePoint и 1С.
1 SharePoint
1.1 Основные преимущества
1.1.1 Прекрасная платформа для разработки портальных решений, систем совместной работы и систем хранения данных. Не требует перезагрузки системы при создании, изменения и удалении структур данных (списки, библиотеки документов, типы содержимого, поля), а также при индексировании полей. Можно наполнять систему любыми данными в RUNTIME.
1.1.2 Выделение типов сущностей в виде типов содержимого, которые можно повторно использовать
1.1.3 Хорошая масштабируемость системы, создание фермы серверов SharePoint - проще простого
1.1.4 Мощный инструмент разработки в виде MS Visual Studio
1.1.5 Раздача прав доступа пользователям и группам Active Directory (AD)
1.1.6 Ограничение прав доступа на уровне записей
1.1.7 Журнал истории изменений элементов списков и документов
1.1.8 Внутренняя файловая система - легко можно перейти с хранения документов на файловой системе на хранение документов в SharePoint
1.2 Основные недостатки
1.2.1 Самым существенным недостатком системы является отсутствие возможности создать транзакцию, которая включала бы несколько операций над данными. В моей практике часто возникали проблемы с рабочими процессами (РП), когда РП ломался из-за ошибки во время выполнения и вернуть его в нормальное состояние было невозможно, РП приходилось начинать сначала. По этой же причине в SharePoint невозможно корректно вести учёт согласованной информации, простое списание суммы из одного документа и её зачисление в другой документ может привести к нарушению целостности данных, т.к. это невозможно сделать атомарно.
1.2.2 Слабая подсистема запросов. Для написания запросов используется язык CAML - язык на основе XML. CAML неудобен в использовании в чистом виде, поэтому приходится использовать сторонние библиотеки такие как Camlex.NET. Запросы с использованием соединений возможны, но в ограниченном виде и с написанием большого количества XML. Поэтому делать аналитические отчёты на основе данных в SharePoint сложно, приходится выгружать данные в Excel для последующего разбора средствами Excel
1.2.3 Все поля элементов списков и документов библиотек хранятся в одной таблице БД "AllUserData", если неправильно организовать работу хотя бы с одним списком коллекции сайтов SharePoint, то можно довести до эскалации блокировок (блокировки всей таблицы) и медленной работы всей системы. По умолчанию в MS SQL блокировка таблицы происходит при блокировки 5000 записей, поэтому в SharePoint есть настройка запрещающая обычным пользователям системы видеть представления, количество элементов в которых превышает 5000 (настраиваемое значение)
2 1С: Платформа 8.1
2.1 Основные преимущества
2.1.1 Транзакции
2.1.2 Управляемые блокировки (управляемая блокировка - это критическая секция исполняемого кода)
2.1.3 Мощная подсистема запросов. Запросы строятся на SQL-подобном языке. Система позволяет создавать временные таблицы, результатом запроса могут быть несколько таблиц данных и т.д.
2.1.4 Мощная подсистема отчётов
2.1.5 Уровень доступа на уровне записей
2.2 Основные недостатки
2.2.1 Для изменения метаданных (структур хранения данных) необходимо переводить базу данных (БД) в однопользовательский режим
2.2.2 Любые изменения данных в системе происходят в транзакции с самым высоким уровнем изоляции (SERIALIZABLE). Это необходимо для финансовых систем, но в системах попроще это лишняя трата ресурсов
2.2.3 Высокая нагрузка на 1С-сервер, через него проходит весь поток данных (чтение/запись)
2.2.4 Доступ только для отдельных пользователей, нельзя дать доступ группе AD
2.2.5 Отсутствие журнала истории изменения объектов
2.2.6 Всю бизнес-логику приходится реализовывать на справочниках и документах, хотя "приятнее" работать с объектами с нужным типом данных
В результате хочется получить платформу обладающую следующими свойствами:
1. Мощный инструмент разработки - Visual Studio и .NET
2. Транзакции с выбором уровня изоляции
3. Управляемые блокировки
4. Изменение метаданных в RUNTIME (изменение метаданных в однопользовательском режиме используются только для структур таблиц и индексирования столбцов БД)
5. Масштабируемость
6. Доступ через группы AD
7. Разграничение прав доступа на уровне записей
8. Подсистема запросов с SQL-подобным языком
9. Журнал истории изменения объектов
10. Внутренняя файловая система
Далее попробую описать основные компоненты платформы:
1 Система бизнес-объектов
Картинка
Основные компоненты системы
* База данных
Метаданные и данные хранятся в одной БД. Т.к. для некоторых изменений в конфигурации системы потребуется перевод БД в однопользовательский режим (такие изменения могут длиться несколько часов), то в системе предусмотрена возможность работы с копией БД в режиме только чтение.
* Контроллер
Основное назначение контроллера - это выполнение операций в транзакции, управление блокировками, формирование наборов изменений (т.к. все изменения данных проходят через контроллер, то он "знает" что и когда изменилось). Наборы изменений нужны для обновления кэш-таблиц общих приложений (в оперативной памяти или на файлах), к которым можно будут "обращаться" запросом.
* Кластер общих приложений
Клиентские приложения работают с кластером общих приложений. В кластер могут входить приложения для работы с различными типами клиентов. Общее приложение взаимодействует с контроллером, но может читать данные из БД напрямую или обращаться к кэш-таблицам, которые поддерживает в актуальном состоянии за счёт наборов изменений формируемых контроллером.
2 Внутренняя файловая система
Картинка
Все объекты системы имеют свой адрес (путь) во внутренней файловой системе (ФС). Внутренняя ФС состоит из основной ФС и неограниченного количества файловых подсистем (ФПС). ФПС оптимизируют работу с объектами конкретного списка, поэтому ФПС реализуется на отдельных таблицах БД. Каждый объект ФС может иметь свой уровень доступа к данным или наследовать его от своего контейнера. Для поиска по всей ФС на уровне БД используются объединения SQL-запросов (UNION).
3 Списки объектов
Картинка
Списки объектов могут хранить объекты разных типов, каждый тип объектов обладает определённым набором свойств. Свойства всех объектов одного списка хранятся в двух таблицах БД - таблице основных свойств и таблице динамических свойств. Структуры этих таблиц в RUNTIME не меняются. Добавленные в RUNTIME новые свойства хранят свои значения в таблице динамических свойств и для одного объекта может создаваться несколько записей в таблице.
Для автоматизации построения иерархий объектов в системе есть зависимые объекты. Зависимость заключается в том, что один объект не может существовать без другого объекта - контрагент и его договоры, подразделения и дочерние подразделения, контрагент и его контактные данные и т.д. Также у зависимого объекта может быть свой номер, например, в счёте есть список товаров, каждый товар счёта - это зависимый объект и может иметь свою позицию в счёте (например, позицию согласно алфавитного порядка).
Для каждого списка объектов создаётся свой журнал версий в отдельных таблицах БД.
4 Подсистема запросов
Картинка
Для выполнения запросов к объектам системы используется SQL-подобный язык. Выражения на данном языке конвертируется в .NET выражения, которые в свою очередь можно конвертировать в SQL-запрос или выполнить на кэш-таблицах.
Для списков можно создавать представления и использовать в запросах. Каждое представление - это SQL-подзапрос. Цель создания представлений - выделение часто повторяющихся подзапросов для переиспользования и упрощения написания и чтения текста запросов.
Приведу примеры представлений:
1. Построение иерархий (иерархия подразделений)
MYQL: SELECT * FROM Departments.Hierarchy() AS D LEFT JOIN Employees AS E ON D.Id = E.DepartmentId
EXPRESSION: EntitySet("Departments").View("Hierarchy").LeftJoin("Employees").On((d,e) => d.Id == e["Department"])
SQL: WITH DepartmentsHierarchy (Id, Title, Level)
AS
(
SELECT D0.Id, D0.Title, 0 AS Level
FROM dbo.Departments AS D0
WHERE D0.Parent IS NULL
UNION ALL
SELECT D0.Id, D0.Title, Level + 1
FROM dbo. Departments AS D
WHERE D.Parent = D0.Id
)
SELECT * FROM DepartmentsHierarchy AS D LEFT JOIN dbo.Employees AS E ON D.Id = E.DepartmentId
2. Подсчёт итогов (группировка товаров счёта с подсчётом суммы)
MYQL: SELECT * FROM OrderGoods.Totals(Title, Sum, OrderGoods.Parent = @OrderId)
EXPRESSION: EntitySet("OrderGoods").View("Totals", new { "Title" }, new { "Sum" }, og => og.Parent == Args[0] /*order id*/)
SQL: SELECT OG.Title, SUM(OGD.Sum) AS Sum FROM dbo.OrderGoods AS OG
LEFT JOIN dbo.OrderGoodsDyn AS OGD
ON OG.Id = OGD.Id AND OGD.RowNumber = 0
WHERE OG.Id = @OrderId
GROUP BY OG.Title
И т.д.
Разработка на платформе сводится к написанию типов объектов, созданию списков нужных типов объектов.
Бизнес-логика строится на свойствах и методах объектов и коде выполняемов в общих приложениях системы.
Общее приложение - это .net приложение, как правило asp.net, но может быть и desktop.
Занимаюсь разработкой на платформах "SharePoint" и "1С: Платформа 8.1" уже более 6 лет, поэтому хорошо понимаю преимущества подобной разработки. Главное - это скорость разработки, использование коробочных продуктов или их переиспользование с требуемой доработкой . Но недостатков у платформ тоже хватает - начав разработку на платформе, попадаешь в её рамки и чем меньше ограничений у платформы тем проще разработка.
Понятно, что любую задачу можно решить используя .NET или Java. Но хотелось бы иметь под рукой инструмент, который бы упрощал решение задач, избавлял от рутинной работы, предоставлял универсальные готовые функции. И поэтому у меня возникло желание создать свою платформу для автоматизации бизнеса и самой разработки бизнес-приложений. В своей платформе хотелось бы сочетать преимущества платформ "SharePoint" и "1С" и по возможности избежать их недостатков.
Начну с описания видимых мной преимуществ и недостатков платформ SharePoint и 1С.
1 SharePoint
1.1 Основные преимущества
1.1.1 Прекрасная платформа для разработки портальных решений, систем совместной работы и систем хранения данных. Не требует перезагрузки системы при создании, изменения и удалении структур данных (списки, библиотеки документов, типы содержимого, поля), а также при индексировании полей. Можно наполнять систему любыми данными в RUNTIME.
1.1.2 Выделение типов сущностей в виде типов содержимого, которые можно повторно использовать
1.1.3 Хорошая масштабируемость системы, создание фермы серверов SharePoint - проще простого
1.1.4 Мощный инструмент разработки в виде MS Visual Studio
1.1.5 Раздача прав доступа пользователям и группам Active Directory (AD)
1.1.6 Ограничение прав доступа на уровне записей
1.1.7 Журнал истории изменений элементов списков и документов
1.1.8 Внутренняя файловая система - легко можно перейти с хранения документов на файловой системе на хранение документов в SharePoint
1.2 Основные недостатки
1.2.1 Самым существенным недостатком системы является отсутствие возможности создать транзакцию, которая включала бы несколько операций над данными. В моей практике часто возникали проблемы с рабочими процессами (РП), когда РП ломался из-за ошибки во время выполнения и вернуть его в нормальное состояние было невозможно, РП приходилось начинать сначала. По этой же причине в SharePoint невозможно корректно вести учёт согласованной информации, простое списание суммы из одного документа и её зачисление в другой документ может привести к нарушению целостности данных, т.к. это невозможно сделать атомарно.
1.2.2 Слабая подсистема запросов. Для написания запросов используется язык CAML - язык на основе XML. CAML неудобен в использовании в чистом виде, поэтому приходится использовать сторонние библиотеки такие как Camlex.NET. Запросы с использованием соединений возможны, но в ограниченном виде и с написанием большого количества XML. Поэтому делать аналитические отчёты на основе данных в SharePoint сложно, приходится выгружать данные в Excel для последующего разбора средствами Excel
1.2.3 Все поля элементов списков и документов библиотек хранятся в одной таблице БД "AllUserData", если неправильно организовать работу хотя бы с одним списком коллекции сайтов SharePoint, то можно довести до эскалации блокировок (блокировки всей таблицы) и медленной работы всей системы. По умолчанию в MS SQL блокировка таблицы происходит при блокировки 5000 записей, поэтому в SharePoint есть настройка запрещающая обычным пользователям системы видеть представления, количество элементов в которых превышает 5000 (настраиваемое значение)
2 1С: Платформа 8.1
2.1 Основные преимущества
2.1.1 Транзакции
2.1.2 Управляемые блокировки (управляемая блокировка - это критическая секция исполняемого кода)
2.1.3 Мощная подсистема запросов. Запросы строятся на SQL-подобном языке. Система позволяет создавать временные таблицы, результатом запроса могут быть несколько таблиц данных и т.д.
2.1.4 Мощная подсистема отчётов
2.1.5 Уровень доступа на уровне записей
2.2 Основные недостатки
2.2.1 Для изменения метаданных (структур хранения данных) необходимо переводить базу данных (БД) в однопользовательский режим
2.2.2 Любые изменения данных в системе происходят в транзакции с самым высоким уровнем изоляции (SERIALIZABLE). Это необходимо для финансовых систем, но в системах попроще это лишняя трата ресурсов
2.2.3 Высокая нагрузка на 1С-сервер, через него проходит весь поток данных (чтение/запись)
2.2.4 Доступ только для отдельных пользователей, нельзя дать доступ группе AD
2.2.5 Отсутствие журнала истории изменения объектов
2.2.6 Всю бизнес-логику приходится реализовывать на справочниках и документах, хотя "приятнее" работать с объектами с нужным типом данных
В результате хочется получить платформу обладающую следующими свойствами:
1. Мощный инструмент разработки - Visual Studio и .NET
2. Транзакции с выбором уровня изоляции
3. Управляемые блокировки
4. Изменение метаданных в RUNTIME (изменение метаданных в однопользовательском режиме используются только для структур таблиц и индексирования столбцов БД)
5. Масштабируемость
6. Доступ через группы AD
7. Разграничение прав доступа на уровне записей
8. Подсистема запросов с SQL-подобным языком
9. Журнал истории изменения объектов
10. Внутренняя файловая система
Далее попробую описать основные компоненты платформы:
1 Система бизнес-объектов
Картинка
Основные компоненты системы
* База данных
Метаданные и данные хранятся в одной БД. Т.к. для некоторых изменений в конфигурации системы потребуется перевод БД в однопользовательский режим (такие изменения могут длиться несколько часов), то в системе предусмотрена возможность работы с копией БД в режиме только чтение.
* Контроллер
Основное назначение контроллера - это выполнение операций в транзакции, управление блокировками, формирование наборов изменений (т.к. все изменения данных проходят через контроллер, то он "знает" что и когда изменилось). Наборы изменений нужны для обновления кэш-таблиц общих приложений (в оперативной памяти или на файлах), к которым можно будут "обращаться" запросом.
* Кластер общих приложений
Клиентские приложения работают с кластером общих приложений. В кластер могут входить приложения для работы с различными типами клиентов. Общее приложение взаимодействует с контроллером, но может читать данные из БД напрямую или обращаться к кэш-таблицам, которые поддерживает в актуальном состоянии за счёт наборов изменений формируемых контроллером.
2 Внутренняя файловая система
Картинка
Все объекты системы имеют свой адрес (путь) во внутренней файловой системе (ФС). Внутренняя ФС состоит из основной ФС и неограниченного количества файловых подсистем (ФПС). ФПС оптимизируют работу с объектами конкретного списка, поэтому ФПС реализуется на отдельных таблицах БД. Каждый объект ФС может иметь свой уровень доступа к данным или наследовать его от своего контейнера. Для поиска по всей ФС на уровне БД используются объединения SQL-запросов (UNION).
3 Списки объектов
Картинка
Списки объектов могут хранить объекты разных типов, каждый тип объектов обладает определённым набором свойств. Свойства всех объектов одного списка хранятся в двух таблицах БД - таблице основных свойств и таблице динамических свойств. Структуры этих таблиц в RUNTIME не меняются. Добавленные в RUNTIME новые свойства хранят свои значения в таблице динамических свойств и для одного объекта может создаваться несколько записей в таблице.
Для автоматизации построения иерархий объектов в системе есть зависимые объекты. Зависимость заключается в том, что один объект не может существовать без другого объекта - контрагент и его договоры, подразделения и дочерние подразделения, контрагент и его контактные данные и т.д. Также у зависимого объекта может быть свой номер, например, в счёте есть список товаров, каждый товар счёта - это зависимый объект и может иметь свою позицию в счёте (например, позицию согласно алфавитного порядка).
Для каждого списка объектов создаётся свой журнал версий в отдельных таблицах БД.
4 Подсистема запросов
Картинка
Для выполнения запросов к объектам системы используется SQL-подобный язык. Выражения на данном языке конвертируется в .NET выражения, которые в свою очередь можно конвертировать в SQL-запрос или выполнить на кэш-таблицах.
Для списков можно создавать представления и использовать в запросах. Каждое представление - это SQL-подзапрос. Цель создания представлений - выделение часто повторяющихся подзапросов для переиспользования и упрощения написания и чтения текста запросов.
Приведу примеры представлений:
1. Построение иерархий (иерархия подразделений)
MYQL: SELECT * FROM Departments.Hierarchy() AS D LEFT JOIN Employees AS E ON D.Id = E.DepartmentId
EXPRESSION: EntitySet("Departments").View("Hierarchy").LeftJoin("Employees").On((d,e) => d.Id == e["Department"])
SQL: WITH DepartmentsHierarchy (Id, Title, Level)
AS
(
SELECT D0.Id, D0.Title, 0 AS Level
FROM dbo.Departments AS D0
WHERE D0.Parent IS NULL
UNION ALL
SELECT D0.Id, D0.Title, Level + 1
FROM dbo. Departments AS D
WHERE D.Parent = D0.Id
)
SELECT * FROM DepartmentsHierarchy AS D LEFT JOIN dbo.Employees AS E ON D.Id = E.DepartmentId
2. Подсчёт итогов (группировка товаров счёта с подсчётом суммы)
MYQL: SELECT * FROM OrderGoods.Totals(Title, Sum, OrderGoods.Parent = @OrderId)
EXPRESSION: EntitySet("OrderGoods").View("Totals", new { "Title" }, new { "Sum" }, og => og.Parent == Args[0] /*order id*/)
SQL: SELECT OG.Title, SUM(OGD.Sum) AS Sum FROM dbo.OrderGoods AS OG
LEFT JOIN dbo.OrderGoodsDyn AS OGD
ON OG.Id = OGD.Id AND OGD.RowNumber = 0
WHERE OG.Id = @OrderId
GROUP BY OG.Title
И т.д.
Разработка на платформе сводится к написанию типов объектов, созданию списков нужных типов объектов.
Бизнес-логика строится на свойствах и методах объектов и коде выполняемов в общих приложениях системы.
Общее приложение - это .net приложение, как правило asp.net, но может быть и desktop.
Исправлено пользователем platform (26.06.14 12:12)
