Подведу-ка я итоги полугодового эксперимента по разработке прототипа некоей учётной системы. На данной предметной области специализируюсь более 10 лет, так что опыт постановки задач мною набран вполне достаточный, и хотелось поднабраться опыта именно в конструировании.

Требования к архитектуре стандартные: трёхзвенка, включающая промышленную СУБД + слой бизнес-логики + клиент. Сверху торчит подсистема аутентификации, авторизации и аудита, а сбоку – подсистема интеграции с учётными системами третьих производителей, включая складские и бухгалтерские системы. СУБД должна быть непременно 1) популярной 2) промышленного уровня, что автоматически исключает из перечня подходящих СУБД всякую экзотику типа DB2, поделки вроде MySQL и сырые штуки наподобие Derby. Собственно, остаются только Oracle и MS SQL. Несмотря на то, что оба этих продукта являются проприетарными, производители предлагают разработчикам бесплатные, хотя и урезанные дистрибутивы в виде Oracle XE и MSDE соответственно. Очень хотелось, чтобы система была кроссплатформенной и могла функциклировать под управлением Линукса, поэтому я с сожалением отложил в сторону Visual Studio и обратил взор на Java.

Итак, с СУБД вопрос решён, осталось покумекать над клиентом и middle-tier.

Броузер в качестве тонкого клиента был смело отвергнут, потому что:
1. Веб был изначально задуман для просмотра порнухи, а вовсе не для создания функционально насыщенных учётных систем. Мне не нравится, что в стандарте HTML до сих пор нет места деревьям и редактируемым таблицам. Не нравится, что элементарное событие – случайное закрытие окна пользователем, который перед этим битый час вводил данные - невозможно отследить единообразным способом. Бесит, что в Опере нельзя использовать самодельные контекстные меню.
2. Отрадно, что есть на нашей планете ремесленники, которые всё-таки умеют делать конфеты из говна (Ext-JS, GWT и т.д.). Но блять такое количество интерпретируемого и плохо читаемого JavaScript-кода должно настораживать и пугать. Я просто не в состоянии понять, как работают эти кортежи вложенных конструкций и замыканий. Я не могу отдебажить ошибку, сообщаемую мне броузером, потому что даже если я буду знать имя файла и номер строки, где случилось исключение, я хуй чё там пойму.

В общем, выбор сделан в пользу толстого клиента. Какого? А не важно, главное, чтобы на Java. И я взял первый попавшийся под руку фреймворк – а именно Eclipse RCP – и закопался в невразумительную документацию по RCP, SWT и Jface.

Документация в мире Java – предмет отдельного разговора. Я даже не хочу упоминать о тех пидарасах, которые вообще не документируют код, или, того хуже, хуячат свои манулы прямо в PDF (который тоже предмет ещё одного разговора). Чё, вам сложно привести пример использования прямо в аннотации пакета, класса или метода? Откройте блять MSDN и посмотрите, как должна выглядеть нормальная документация. Впрочем, ладно – на худой конец, если юзаемая библиотека реально работает, я готов смириться, свалить все мануалы до кучи и натравить на них Google Desktop. Жить можно.

Спустя три месяца я через мат-перемат научился ваять на SWT вполне сносные окошки, как настоящий брутальный программист – инициализируя лэйауты и контролы прямо в коде. «А что, в Java визуального дизайнера нет?» - спросите вы. А это смотря какую визуальную библиотеку вы используете и в какой среде разработки. Если взялись за Swing – то самый классный редактор UI есть в Netbeans. Но в Eclipse, для SWT - такого нет. А есть плагин Visual Editor для редактирования гуя. Но вот незадача – его актуальная версия почти всегда отличается от актуальной версии Eclipse на один пункт. То есть плагин 3.2. не работает в Eclipse 3.3. Для того, чтобы выяснить, почему ЭТО не работает, вам придётся убить как минимум час времени на гугление и, что самое неприятное, в конце концов отказаться от заманчивой идеи визуального проектирования формочек. Или, как это принято в мире UNIX, кочать сорцы и затачивать их рашпилем под свои нужды. Уф.

Далее. После того, как SWT был освоен и первый плагин был торжественно запущен, было принято решение его почикать-декомпозировать на несколько самостоятельных Eclipse-плагинов. Сказано-сделано. Поначалу всё работало прекрасно. Пока я не столкнулся с комплексной проблемой конфликта манифестов. Её суть в том, что формат манифеста плагина Eclipse RCP должен соответствовать неким скверно документированным правилам, гласящим, что в манифесте нужно прописывать как все зависимости на другие плагины, так и все выставляемые плагином наружу пакеты (это делается, слава аллаху, с помощью визуального редактора манифеста). Но. Если в этом же Workspace существует Java project, не являющийся плагином, то его подключить к другому плагину НЕЛЬЗЯ. Нужно либо скомпилировать этот проект и подключить к плагину jar-файл, либо переконвертировать проект в RCP. Но в последнем случае, если мы попытаемся подключить RCP-плагин к, скажем, проекту веб-приложения, то с вероятностью в 50% получим плавающий ClassNotFoundException при попытке обратиться к любому из классов, определённых в проекте плагина. Подозреваю, это происходит потому, что эксплуатируемый контейнер сервлетов и инфраструктура Eclipse используют разные класслоадеры.

Но самые большие разочарования постигли меня с Middle-tier. Суть идеи была проста – использовать обычную модель оторванных данных, по схеме: выполнить запрос, закачать данные в Transfer Objects, отдать сервисом клиенту на редактирование, принять от клиента изменённый пакет данных, выполнить обновления в базе. В .NET это делается при помощи датасетов и веб- или remoting-сервисов с полтыка. Аналога System.Data.DataSet и вообще ADO.NET в мире Java я не нашёл. В поздних JDK в пакете javax.sql появились несколько классов, реализующих интерфейс RowSet, которые, по заверениям товарищей из Sun, гарантированно являются сериализуемыми наборами данных и их можно гонять между процессами и по сети. Первая же попытка получить WSDL из класса сервиса при помощи инфраструктуры Axis, один из методов которого возвращал JoinRowSet, привела к тому, что мастер публикации веб-сервиса честно предупредил меня о том, что JoinRowSet не является Java-бином и привёл его к типу Object.

Ладно, подумал я, - а как же обстоят дела с модными нынче ORM/POJO? Hibernate оставил на сладкое и взял в руки Apache IBatis. Название блять в точку. Но ибатился я недолго, хватило воли вовремя взять себя в руки и переключиться на Хибернейт.

Хибернейт – вообще вещь в себе. Альфой и омегой Х прежних версий, насколько я знаю, являются XML-файлы, в которых описываются всякие там параметры ORM-мэппинга чуть ли не для каждой сущности. Вообще я ненавижу XML. Точнее, ненавижу нестандартный XML – это когда каждый задрот придумывает свой гениальный формат описания чего-то-там и пытается донести его до общественности. Реально работающих стандартов на основе XML в мире ровно три – это XSLT, XSD и WSDL. Всё остальное – это кал, в котором и ковыряться-то неохота. Поэтому раздел документации Hibernate, посвящённый описанию XML-схем маппинга, я пропустил и сразу перешёл к разделу, описывающему реализацию EJB 3.0 – то бишь аннотациям.
Тестовый проект, включающий в себя десяток таблиц, в том числе и с достаточно сложным мэппингом типа «многие-ко-многим», как ни странно, на аннотациях заработал сразу и без нареканий. Но работал он ровно до тех пор, пока я не подключил хибер к… догадались? Да, плагину эклипса. Это был просто праздник. Начнём с того, что в режиме отладки плагина конфигуратор Хибера упорно не желал находить файл persistence.xml, если тот находился не в папке META-INF, которая в свою очередь ОБЯЗАТЕЛЬНО должна была лежать в папке src проекта. Это я победил. Далее, если плагин, дергающий хибер, вызывался из другого плагина, то даже такое хитрожопое размещение persistence.xml не помогало – я ради развлечения создал десяток его копий и распихал во все возможные места – не помогало, хибер его упорно не находил. Тогда я захардкодил конфигурирование Hibernate в коде java. Это помогло. Но. Встала проблема автоматического вытягивания зависимых объектов по связям. Если я хочу сериализовать объект и передать его в «оторванном» виде на другую машину по сети, то есть риск того, что за этим объектом высосутся полбазы данных, если мы все связи пометим для ранней загрузки (earlier fetching) или риск того, что объект придёт клиенту «пустым» в случае использования lazy fetching. Такой риск минимален, если клиент и сервер живут на одной машине - например, в архитектуре веб-приложения все связи можно помечать lazy и не бояться, что хибренейт выкачает что-то лишнее, но если мы используем disconnected-модель и «толстого» клиента, то хибернейт для задачи формирования пакетов данных, скажем прямо, не пригоден.

В общем, серебряную пулю я так и не нашёл и вчера торжественно отправил Java на помойку.