Java для SMB
Василь Гринюк
Безперечно,
java є одним з лідерів на ринку складних корпоративних продуктів.
Прекрасна масштабованість і надійність - основні фактори цього успіху. Але
чи варто вдаватися до такого потужного інструменту, коли масштабованість НЕ
дуже і важлива? Адже для невеликих компаній більш важливим є вартість
розробки та її строки, а також можливість швидко відреагувати на зміни в
діяльності компанії і при необхідності змінити програмний продукт. А для
інтернет-стартапів і зовсім потрібно якомога швидше реалізувати первинний
начерк бізнес-ідеї і при цьому з максимально привабливим інтерфейсом. І
практично перед кожною компанією стоїть вибір - замовити програмне рішення
«Під ключ» або спробувати знайти вже готове і адаптувати під свій бізнес.
Microsoft також не відстає і з виходом net framework 2.0 і ms ajax намагається
захопити ринок. Щоб відповісти на питання, чи підходить java для розробки
програмних рішень, потрібних середньому та малому бізнесу, подивимося, для якого
роду завдань її можна ефективно застосовувати, де виявляються її переваги.
Будь-яке
додаток складається з декількох шарів. Зазвичай це модель і графічний
інтерфейс. У випадку, якщо логіка програми досить складна, з'являється ще
один шар між моделлю і інтерфейсом - це сервіси. Модель містить у собі всю
основну логіку програми - бізнес-логіку, включаючи бізнес-об'єкти і
бізнес-процеси, які необхідні для поставленої задачі. Сервіси - це
шар, який надає більш зручні методи для вирішення задач відображення,
редагування та додавання даних в інтерфейсі. Зупинимося
більш детально саме на моделі, тому що вона фактично є ядром системи,
працездатність і ефективність програми в більшій мірі залежать саме від
неї. Від способів її реалізації також залежить, наскільки складно буде в
надалі вносити зміни у додаток.
Hibernate
Перший
питання при проектуванні моделі - як і де зберігати дані? Очевидно, що
краще всього в базі даних, але в якій саме і як організувати комунікацію
між додатком і конкретної СУБД? Тут нам на допомогу приходить практично
революційний фреймворк-Hibernate. При роботі з ним практично повністю
відпадає необхідність дбати про те, що дані десь повинні зберігатися.
Розберемося
в ньому більш детально. По-перше, Hibernate є почасти абстракцією над
СУБД, а це означає, що програма більше не прив'язане до конкретного серверу
бази даних. Наприклад, для того щоб перейти з легкою та зручною СУБД MySQL на
дуже продуктивний Oracle, потрібно всього лише у файлі конфігурації
поміняти назву діалекту. По-друге, Hibernate-це засіб для об'єктного
маппінг даних, тобто фактично., ми маніпулюємо зв'язками об'єктів, а не
просто структурованими даними. Ми не дбаємо про те, як ці об'єкти будуть
зберігатися в конкретній СКБД, і про те, як ці об'єкти (а точніше, їх зв'язки)
зберігати або отримувати з бази даних.
В
зв'язку з тим що при роботі через Hibernate ми ніколи не стикаємося з
будь-якими специфічними для різних СУБД функціями, то прив'язки до конкретного
сервера не існує. Насправді нам навіть не доводиться писати SQL-запити
або самим створювати структуру бази даних. Структуру Hibernate створює сам при
завантаженні програми. А ось із запитами ще цікавіше. Запити пишуться на його
власній мові - HQL (Hibernate Query Language). Ця мова має деякі
логічні схожості з SQL, але не більше. По-перше, ця мова оперує не з
таблицями та їхні оселі, а з об'єктами і їх зв'язками. По-друге, на цій мові
пишуться тільки запити на отримання зв'язок об'єктів, а точніше, складні пошуки.
Для вибірки даних без складної логіки він не потрібний, тому що є таке поняття,
як критерій, цього цілком вистачає, якщо не потрібно вести пошук з урахуванням значень
в дочірніх об'єктах.
Є
два способи «навчити» Hibernate працювати з нашими об'єктами - маппінг і
анотації. Обидва способи вказують Hibernate, які саме поля нашого об'єкта
потрібно зберігати і як цей об'єкт розташований в нашій ієрархії: які у зв'язку
цього об'єкта з іншими об'єктами (один з багатьма, багато хто з багатьма, багато з
одним). Завдяки цьому, отримуючи об'єкт з бази даних, ми отримуємо і всі його
дочірні об'єкти. При цьому використовується таке поняття, як lazy loading.
Завдяки йому Hibernate не відразу передає нам всю зв'язку об'єктів (це могло б
призвести до того, що отримуючи один об'єкт, який так чи інакше пов'язаний з
іншими, довелося б отримати все, що зберігається в базі даних), а якісь
персистентності посилання. І лише при першому реальному зверненні до цього об'єкта
дістає його. Ще один приємний момент - це простота реалізації ВАТ (DataBase
Access Object). Можна просто зробити єдиний ВАТ-клас для всіх об'єктів.
Всі стандартні методи (save, delete, update) надає сам Hibernate, про
них нам піклуватися не потрібно зовсім. А для складних методів, що використовують
HQL-запити, досить зробити метод обгортку, який буде читати по
якому-небудь ключу сам запит з xml-файлу і повертати нам список наших
об'єктів. Наступним важливим моментом є те, що Hibernate працює в
транзакційних режимі, що важливо для безпеки зберігання даних. Це
дуже критично, наприклад, в будь-яких бухгалтерських програмах. Однак це потрібно
враховувати ще під час планування, так як необхідний постійний контроль
стану транзакцій. Наприклад, після закриття транзакції все lazy-дані будуть
недоступні.
Spring
Ще
один потужний фреймворк - Spring. Він дозволяє зберігати будь-які об'єкти як біни. Те
Тобто ми вказуємо інтерфейс і його реалізацію, a Spring вже створює екземпляр
цього класу і поміщає його в контекст. Цей бін доступний всьому програми і
буде існувати весь час, поки додаток запущено. Це дуже зручно, тому
як ми можемо помістити в контекст наші ВАТ-об'єкти і бути впевненими, що під
всіх частинах програми використовується один і той же екземпляр. Але тільки, якщо
нам це потрібно.
Те
Тобто ми безпроблемно можемо створити та сесій біни, і тоді для кожної сесії
буде створюватися свій особистий бін. Це досить «легкий» фреймворк і
завдяки йому можна повністю відмовитися від такого громіздкого контейнера, як
JBoss, обійшовшись «маленьким» Tomcat'oM. А це суттєво знижує апаратні
вимоги.
Web 2.0
Тепер
подивимося, як можна швидко і ефективно реалізувати front-end. Враховуючи, що
Web 2.0 вже фактично повністю став стандартом, зупинимося саме на ньому.
Якщо коротко, Web 2.0 - це сайти, сторінки яких не є статичними, а
зміна вмісту відбувається не за допомогою перезавантаження сторінки, а при
допомоги JavaScript через асинхронні запити, простіше кажучи, AJAX (Asynchronous
JavaScript and XML). Яскраві приклади такого-інтерфейсу Gmail і Google Maps. Є
два способи реалізувати AJAX-інтерфейс - самому писати JavaScript'и і
використовувати будь-які RPC (наприклад, JSON-RPC), або використовувати готовий
фреймворк. Одні з найкращих фреймворк для створення інтерфейсу Web 2.0-це GWT
(Google Web Toolkit), dojo або Tapestry 4.1 + Tecas. У всіх способів є свої
плюси і мінуси. Підемо по порядку.
Головним
мінусом першого варіанту є те, що у команди повинен бути досить
великий досвід у розробці такого інтерфейсу і бажано наявність власних
заготовок. Головний плюс-те, що програмісти мають повний контроль над усім,
що вони роблять, і немає ніяких обмежень, що накладаються тим чи іншим
фреймворком. Гарне допоміжний засіб - JSON-RPC. Він передає дані не
у форматі xml, а в спеціальному форматі JSON, надаючи дуже зручний спосіб
безпосередньо викликати методи на сервері і отримувати відповідь вже в готовому об'єктному
поданні. Це дуже зручно, тому що можна повністю використовувати
об'єктну модель на клієнті. Він підтримує передачу складних об'єктів, списків
і т. д. Але є кілька моментів, про які не варто забувати при роботі з
JSON-RPC. Наприклад, реєструвати всі сервіси потрібно в кожній сесії окремо,
в залежності від того, ким авторізовивался користувач. Тоді вам не доведеться
реалізовувати систему безпеки у бізнес-логіці. І якщо команда має
великий досвід роботи з об'єктно-орієнтованим програмуванням на JavaScript
і хоча б невелику колекцію напрацювань, то цей підхід є досить привабливим і
ефективний.
Другий
підхід-використання готового фреймворку. Він не простіше чи швидше, це просто
альтернатива. По-перше, кожен фреймворк має свої особливості, по-друге, у
кожного з них є свої «підводні камені». Це означає, що команда повинна
мати досвід роботи з цим фреймворком. І чим цей досвід більше, тим більше
толку від його використання. Ще варто додати, що більшість фреймворком
розраховані на вирішення конкретних завдань - крок вліво зробити дуже складно. А в Ul
(User Interface) це дуже і дуже проблематично. Адже реально практично у
будь-якого проекту є свої унікальні вимоги до представлення даних. Тому
вибирати фреймворк потрібно або такий, в якому точно передбачено все, що
потрібно, або такий, що легко розширюється. Давайте подивимося на деякі
фреймворки ближче.
GWT
В
черговий раз нас порадувала компанія Google. Це й не дивно, адже в
створення інтерфейсів Web 2.0 вона набралася чимало досвіду-фактично вона
займає лідируючі місця в цій області: Gmail, Google Map, Google
Docs & Spreadsheets. Рішення у Google вельми цікаве і незвичайне - ми
пишемо весь код на Java. Спеціальний компілятор компілює Java-код у
JavaScript-код. Причому цей код підтримується у всіх браузерах. Код, який
пишеться, оперує зі стандартними Java-класами, такими як ArrayList,
HashMap, HashSet і т.д. Додатково реалізовані всі класи, потрібні для
інтерфейсу (Button, Window і т. д.). Тобто цей код компілюється стандартним
Java компілятором і можна безпроблемно писати unit-тести та запускати їх. До
жаль, поки що підтримується тільки компілятор версії 1.3, який, до
Наприклад, не містить ітеративних циклів. Але ми отримуємо реальний контроль типів
(принаймні, під час компіляції), можливість зручно записувати класи,
та й взагалі відсутність більшості проблем, які виникають при написанні
коду на скриптових мовах. Додатково пропонується система зв'язку клієнта з
сервером. Тобто фактично повноцінний RPC. Хоча модель цієї системи не така
проста і наочна, як у JSON-RPC, вона все ж таки ефективна. І не дивлячись на те
що писати нескладні програми та інтерфейси, використовуючи GWT, щодо
просто, для серйозного використання потрібно хороший досвід роботи з ним,
особливо в архітекторів системи.
DOJO
DOJO
- Ще один цікавий toolkit (як він сам себе називає). Це дуже велика
бібліотека компонентів, написаних на чистому JavaScript. У ній містяться
практично всі необхідні компоненти для інтерфейсу будь-якої складності. Але є
один недолік - ще досить велика кількість помилок і недоробок. Коли
вони будуть виправлятися - питання. Але враховуючи, що це plain-javascript, при
необхідності виправити те, що реально потрібно, можна й самим. А плюсом є
те, що цей toolkit пропонує досить просту і логічну модель PRC.
Maven
Ще
одне дуже зручне, незамінний засіб для будь-якої команди розробників --
maven, або так званий build-tool. Крім того що він дозволяє легко
компілювати проекти, він дає можливість команді працювати в різних
редакторів-як-то кажуть, на смак. Просто описав в спеціальному файлі структуру
проекту і його залежності від сторонніх бібліотек, він автоматично завантажує
потрібні бібліотеки з Інтернету або будь-яких інших зазначених джерел при
компіляції або створення проектних файлів для більшості популярних
редакторів, таких як IntelliJ IDEA або Eclipse. Дуже зручно те, що він
підтримує багатомодульним проекти, це дозволяє розділити логіку програми,
і правильно створює ієрархічні зв'язку модулів в IntelliJ IDEA. Можна
подумати, що це аналог Ant'a, але це не так. Це повноцінно новий рівень
збирача проекту, з яким Ant порівнювати не має сенсу.
IntelliJ IDEA
До речі,
про редактори. Досить багато Java-розробників досі користуються таким
редактором, як Eclipse. Що в принципі зрозуміло, адже він повністю безкоштовний.
Але чи варто економити кілька доларів і при цьому сильно програвати по
функціоналом? Одним з найбільш потужних редакторів - саме IntelliJ IDEA. Він
має просто неосяжний функціонал в базовій комплектації, а якщо все-таки
комусь цього здасться мало, то і величезну бібліотеку додаткових плагінів.
Головна відмінність цього середовища розробки - багатомодульним проекти. Прекрасний
інтерфейс тільки доповнює загальну картину. Чудові можливості, починаючи від
складних моментів у рефакторінг і закінчуючи дуже непоганим аналізатором коду,
автоматичним контролем за стилем написання і вбудованим клієнтом контролю
версій.
Висновок
Придатність
Java для проектів, які потребують швидкої розробки і потужної віддачі, стає
очевидною. Просто потрібно підібрати правильний підхід. Іноді варто витратити частину
коштів і часу саме на пошук максимально ефективних способів вирішення
проблеми за допомогою JAva, а не намагатися вирішувати її в лоб стандартними або
доступними з якихось причин засобами.
Список літератури
IT
спец № 07 ЛИПЕНЬ 2007
