Кашуков Андрей

Экватор.
Сегодня был 2-й день изучения Аксапты.
От изучения языка перешли к изучению системных объектов и среды разработки MorphX в целом.
Дальше, глубже, детальнее.
По ощущениям: с каждым разом система нравится мне все меньше и меньше.

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

Аксапта поддерживает только две СУБД — либо “родной” MS SQL Server, либо “вражеский” Oracle.

На деле это выглядит, например, так: в среде разработки можно создать связи между таблицами (или внутренними объектами а-ля расширенные стандартные типы переменных — extended data types), которые напрашиваются на звание внешних ключей в СУБД.
Другие среды разработки так и делают и потом успешно об этом забывают: за целостностью данных следит сама СУБД и все счастливы.
Но так как среда разработки в Аксапте — это мега-универсальный ERP-инструмент, то (внимание!) внешние ключи в СУБД не создаются, а за связями между объектами следит сама Аксапта (читай — сервер приложений).
Пишу со слов обучающего нас специалиста (у меня нет оснований ему не верить, ибо писал в Аксапте он, по всей видимости, долго).

То есть, что получается.
Сервер приложений берет на себя функции СУБД, расширяя их вглубь и вширь, заменяя SQL своим языком и при этом “выкидывая” некоторые СУБД-специфичные вещи, являясь по сути “прокладкой” или набором API.
Даже более того: вследствии “размытия” ответственности, часть функционала СУБД надо писать самому (!).
Например, в среде разработки у таблиц есть субобъекты, отвечающие за поведение записей в дочерней таблице при удалении записей в главной (delete). Это стандартное свойство внешних ключей каждой уважающей себя СУБД. При этом, напомню, внешние ключи не создаются. Но! Нет объектов, моделирующих поведение при обновлении (update). Их надо создавать руками.

Есть еще примеры в тему, но перечислять их не буду, дабы не утомлять подробностями.
В результате и сервер приложений, и сам программист начинают эмулировать работу СУБД, изобретая новые велосипеды.

На вопрос: что будет с проектом, если кто-то нарушит целостность данных извне (читай — в самой СУБД) был дан ответ — так как сервер приложений первичен — он сам синхронизирует данные и восстановит структуру таблиц в СУБД. То есть СУБД используется просто как хранилище информации — и не более (напомню — это вернеэшелонные системы MS SQL Server или Oracle). Не совсем понятно, зачем это было сделано (теоретически — для унификации работы с разными СУБД, фактически — каждая из них умеет это все отлично делать и на порядок больше). С таким успехом список поддерживаемых СУБД можно было расширить до максимума — любая из них хранит данные и “отдает” их по запросу.

Это все перекрывается словами: “зато тут между объектами можно сделать мега-связи. Посмотрите — вот тут даже можно временные таблицы сделать (о которых СУБД и не знает — прим. редактора) или связи со встроенными объектами наладить. И нетривиальные, с фильтрами и выбором данных из нескольких несвязанных таблиц при вводе в разные ячейки”.

У таблиц (которые внутри являются ООП-классами), как оказалось, отсутствуют некоторые стандартные, казалось бы, функции. Например, нет стандартного механизма поиска записей (!!!) или проверки в таблице текста на существование (exist). Это вполне можно было сделать в родительском для всех таблиц объекте, благо, другие методы в нем присутствуют.

Что еще удивило: почему в качестве языкового ООП-прототипа была выбрана именно Java (напомню: X++ = Java + SQL + C++). А не .Net. Даже странно, так как мелкомягким сам бог велел использовать .Net, продвигаемый ими сейчас. Очень странно (но меня, как джава-программера сей факт, безусловно, радует).

В общем, ладно.
Завтра будет третий и последний день обучения.
Вследствие большого количества вопросов (а куда без них — это же потенциальные грабли) завтра мы приедем на час раньше и закончим на час позже.
Ибо от графика отстали заметно.
Одно радует — я не буду (надеюсь) заниматься внедрением Аксапты и буду лишь дорабатывать ее после запуска под нужды моей организации. Но даже в этом случае многосторонний секс с “флагманским решением для управления предприятиями” неминуем.
Время покажет.

Да, чуть не забыл.
Завтра будет самое интересное — классы.
Надеюсь, хоть немного пойму объектную модель Аксапты изнутри.
И смирюсь через месяц-другой.

Создано : 10.10.2007 19:16 в 19:16 находится в разделах Java, Полуличное.