Блог

Уважаемое сообщество Stack Overflow,

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

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

Серверная часть

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

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

Интерфейс

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

Мои цели

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

Что я уже решил для

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

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

• GWT с GIN-jection во внешнем интерфейсе
  кажется мне лучшим вариантом, потому что я хорошо знаком с 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 Framework, или я мог бы продолжать использовать Guice?

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

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

Заранее благодарю вас! eQui

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

http://thedailywtf.com/Articles/Programming-Sucks !-Или-По-крайней мере,-это-должно-быть-.aspx

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

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

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

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

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

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

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

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

DB и ORM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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