Сложное управляемое данными веб-приложение на Java - решение по технологиям - PullRequest
3 голосов
/ 12 апреля 2011

Уважаемое сообщество переполнения стека,

Я - программист на Java, выполняющий задачу по созданию сложного веб-приложения, управляемого данными (SaaS), и я ищу технологии для использования. Я уже принял некоторые решения, и я считаю, что я достаточно опытен, чтобы построить приложение, используя только технологии, для которых я решил (я определенно не говорю, что это было бы идеально, просто это работало бы). Тем не менее, я хотел бы облегчить мою задачу, и поэтому мне нужна ваша помощь.

Краткое описание проекта

Back-конец

Приложение будет сильно управляемым данными , что означает, что все будет храниться в базе данных с самоописанием. Это означает, что сама база данных будет полностью описана метаданными, и приложение не будет знать, какие данные она читает и записывает. Вероятно, не будет никаких регулярных объектов (с точки зрения JPA @Entity), потому что приложение не будет знать структуру данных; он получит его из метаданных. Только метаданные будут иметь предопределенную структуру. Проще говоря, метаданные - это альфа-омега приложения, потому что они сообщат приложению, когда и что отображать, и как отображать.

Приложение, вероятно, будет использовать хранимые процедуры для выполнения некоторых низкоуровневых задач с данными, таких как автоматический аудит, ведение журнала и перевод на язык пользователя, что, скорее всего, исключит любую возможность использования каркасов ORM, потому что не будет просто простые операции CRUD. Поэтому JDBC кажется моим единственным вариантом (не так ли?).

Фронтальный

Пользовательский интерфейс будет «тупым» с точки зрения того, что он не будет знать, какие данные он отображает (в некоторой степени, конечно). Он просто будет знать, как отображать его на основе метаданных, которые он получит из базы данных. Все элементы управления пользовательского интерфейса (например, пункты меню, кнопки и т. Д.) Будут созданы на основе текущего состояния приложения, и пользовательский интерфейс НЕ будет знать, что делают элементы управления. Это означает, что нажатие на элемент меню или кнопку просто отправит идентификатор связанного действия на сервер, и сервер решит, что делать.

Мои цели

Моя главная цель - сделать приложение как можно более легким и иметь как можно меньше зависимостей. Поскольку приложение будет очень сложным, я бы хотел избежать каких-либо тяжелых фреймворков, потому что существует очень высокая вероятность того, что мне потребуется настроить большую часть его функциональных возможностей.

То, что я уже решил

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

  • Сервлеты на Tomcat, Guice DI , AOP ( AspectJ )
    Я считаю, что все эти технологии достаточно легки, и мне не нужно изучать J2EE.

  • GWT с GIN -инжекцией на передней панели
    Кажется, это лучший вариант для меня, потому что я очень хорошо знаком с Java и Swing и не хочу писать Javascript, PHP или изучать новый язык. GIN - младший брат Guice, и я буду использовать один и тот же синтаксис и принципы как на клиенте, так и на сервере.

  • MSSQL RDBMS
    На самом деле это требование руководства компании, так как я бы предпочел использовать решение с открытым исходным кодом. Слишком плохо для меня ..

  • Maven 2
    Я думаю, что никто не может возразить против этого:)

Что мне нужно помочь с

  • Связь с БД Я думаю, что ORM исключен (не так ли?), Поэтому мне нужно использовать JDBC.Как вы думаете, Spring JDBC легок и достаточно гибок для моего использования?Мне часто приходилось «слепо» читать данные из базы данных, сопоставлять их с какой-либо общей сущностью (потому что я не буду предполагать какую-либо заранее определенную структуру), а затем отправлять данные с помощью некоторого общего DTO клиенту вместе с сообщением метаданных.что это за данные и как их отображать.Или вы знаете какие-либо альтернативы?Или я должен сделать это сам?

  • Связь клиент / сервер GWT и его механизм GWT-RPC, похоже, не очень подходят для отправки необходимых мне общих данных.Хотя я убежден, что это возможно с помощью GWT-RPC, есть ли альтернативы?Но я определенно хочу использовать GWT.

  • Безопасность Знаете ли вы какие-нибудь библиотеки / фреймворки безопасности, которые бы мне помогли?Я знаю о существовании Spring-security;Как вы думаете, это достаточно гибко для моего использования, или я бы лучше сам это реализовал?Кроме того, IoC Spring является неотъемлемой частью среды Spring или я смогу продолжать использовать Guice?

  • Что-нибудь еще , которое, по вашему мнению, может быть полезным?

Я очень ценю любые советы и предложения, потому что я не осмелился бы попытаться принять такие решения самостоятельно.Пожалуйста, спросите меня, если вам нужна дополнительная информация.

Спасибо заранее!обор

Ответы [ 4 ]

2 голосов
/ 12 апреля 2011

Я думаю, что вы чрезмерно разрабатываете решение.Взгляните на

http://thedailywtf.com/Articles/Programming-Sucks!-Or-At-Least,-It-Ought-To-.aspx

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

Я также предлагаю вам взглянуть на Spring Roo, если ваше приложение в основном просто обновляет данные в базе данных.

1 голос
/ 14 апреля 2011

Структура пользовательского интерфейса и последствия для взаимодействия клиент / сервер

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

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

Фреймворк, такой как ZK или Vaadin, кажется более подходящим для того, что выхотеть сделать.На стороне клиента есть хорошие виджеты с богатым пользовательским интерфейсом, но вы манипулируете пользовательским интерфейсом со стороны сервера.Фреймворк управляет связью клиент / сервер для вас (не требуется REST, RPC или javascript).Основным ограничением этих тезисов является масштабируемость, со всеми тезисами в обе стороны.Но так как ваши требования навязывают такое болтливое поведение, вы могли бы действительно извлечь выгоду из предоставляемой ими абстракции, если в вашем случае они бесплатны.

Я попробовал и GWT, и Zk сделать некоторое подтверждение концепциимоя компания.Мы перестали выбирать GWT, потому что его можно было легко встроить в любой существующий пользовательский интерфейс и точно настроить то, что вы делаете ... В частности, избегайте как можно большего проникновения на сервер.Но ZK действительно проще и быстрее с точки зрения времени разработки.

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

DB и ORM

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

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

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

Поэтому я бы попытался описать пользовательский интерфейс в каком-либо шаблонном или XML-формате.Возможно, вы не будете показывать эти данные пользователю, предоставляя им хорошую абстракцию, но вместо того, чтобы выполнять много запросов только для одного экрана, вы сохраните весь экран как один большой двоичный объект.

Действительно тупойи основная реализация этого заключается в том, чтобы хранить файл HTML / CSS / PNG в вашей БД и загружать его по мере необходимости, при этом пользователь несет ответственность за создание этого файла HTML вручную.Конечно, это было бы ужасно для пользователя.Вот почему вам нужен приятный и модный редактор пользовательского интерфейса, который будет работать на собственном промежуточном формате.Еще одна глупая реализация - это своего рода шаблон вики.Это не то, что вам нужно, вам нужно больше.Но у вас есть идея, я бы искал в этом направлении ...

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

Безопасность

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

Надеюсь, это поможет ...

1 голос
/ 14 апреля 2011

Я думаю, что вы на правильном пути, с вашим выбором инструмента.Вашу модель, основанную на 100% данных, будет сложно поддерживать.Но я понимаю, что это требование, а не вариант.Нормальное управление исходным кодом потерпит неудачу, потому что логика пользовательского интерфейса все в метаданных.Вам понадобятся хорошие тестовые базы данных и какой-нибудь способ их обслуживания, такие как регулярное выполнение mysqldump и проверка их для обеспечения контроля кода для обработки всех различий и т. Д.

Вы должны остатьсяот различных решений ORM и просто используйте JDBC для этого типа приложений.

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

1) Если абстракция не удалась, как вы легко отлаживаете?

2) Хотите ли вы, чтобы какой-либо ваш сайт был виден для Google или других поисковых систем, если да, GWT не для вас

3) Хотите использовать какие-либо техники HTML5 или делатьВы хотите застрять в режиме совместимости IE 5?

Итак ... Я думаю, вам будет намного лучше реализовать пользовательский интерфейс в виде простых элементов управления HTML с небольшим набором jQuery ajaxвзаимодействия с сервером.Вы можете определить тип ввода в вашей базе данных, ваш серверный сервер может сгенерировать тег ввода, а затем у вас есть две опции, которые вы можете использовать в jquery для стандартных привязок событий, чтобы сообщить вашему серверу эту кнопку1.щелчок, или что select2 изменился, и т. д. Ваш сервер может отправить обратно javascript, чтобы изменить состояние пользовательского интерфейса - просто загрузите javascript внутри div, чтобы он работал на клиенте.или 2) Вы позволяете входным данным отправлять данные на сервер и обновляете страницу старой школы, а сервлет создает следующий экран пользовательского интерфейса на основе базы данных.

Динамическое построение интерфейса в HTML из базы данных легко и просто по сравнению с тем же в SWING или Windows Forms.Вам просто нужно написать большую текстовую строку, делая это с 1999 года.

Такой подход будет гораздо более легким - проще отлаживать, понимать и модифицировать в долгосрочной перспективе, чем с помощью "GWT"автоматически компилируется в нечитаемый javascript, который не запускается в моем браузере по неизвестной причине ".

1 голос
/ 14 апреля 2011

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...