Диспетчер документов архитектурный вопрос - PullRequest
0 голосов
/ 07 декабря 2010

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

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

Было бы замечательно, если бы SO гуру могли наставлять меня в этом или дать мне толчок в правильном направлении.

Редактировать: Спасибо за ответ. Это стандартная трехуровневая архитектура, которая была описана в ответе. Мне нужна огромная масштабируемость, и, поскольку приложение будет в первую очередь ориентировано на документы, и мне, возможно, придется обновить поиск позднее, я бы хотел отказаться от СУБД. Поскольку в настоящее время огромное количество пользователей публикует свои документы (скажем, * .txt), мне понадобится какая-то очередь сообщений для обработки этого огромного потока информации. Должен быть какой-то слой быстрого преобразования, который берет документы во всех его форматах и ​​отображает их в формате, подходящем для аннотаций и разметки .... и этот список можно продолжить. Начинать с модели предметной области и двигаться вниз было бы идеально, но я немного скептик.

Ответы [ 2 ]

1 голос
/ 08 декабря 2010

Не совсем "полный ответ", но, надеюсь, немного пищи для размышлений.

Я использую этот проект в качестве упражнения для разработки масштабируемого / безопасного / быстрого веб-приложения с использованием инструментов с полностью открытым исходным кодом ...

Это великолепно, поэтому мой вопрос: зачем беспокоиться об архитектуре? Я признаю, что это немного странно, если исходить от того, кто считает себя сторонником архитектуры, но «изучение архитектуры» и изучение новых технологий могут быть сложными. Может быть, вы просто хотите сначала ускориться, а затем заняться другим?

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

Изменить:

Я бы начал с того, что было для вас важнее; затем, когда я начну с «другой» темы, я буду постоянно проверять то, что я изучил / мои предположения.

В зависимости от двух предметов могут быть некоторые «синергии», которые предполагают другой подход. Часть меня хочет порекомендовать сделать достаточно для одной, чтобы получить хорошее базовое понимание, а затем поднять другую до аналогичного уровня, а затем двигаться дальше. Таким образом, вы будете более последовательны.

Другая часть меня говорит - просто делай то, что интереснее!

Должен ли я исследовать глубины заданного технологического стека, прежде чем двигаться вперед, или получить план прямо с точки зрения независимости от инструмента?

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

Или мой план изменится из-за технологических ограничений?

Под этим я предполагаю, что вы имеете в виду, что: если вы обнаружите, что «данная технология работает таким образом» и как она работает, отличается от того, что вы ожидали - тогда это повлияет на план?

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

На высоком уровне все, что вам нужно сделать, это убедиться, что вы не ограничиваете варианты в дальнейшем.

1 голос
/ 07 декабря 2010

Я парень из Java. Как бы я подошел к этой проблеме, будет

  1. Выяснить модель данных. Какие объекты будут использовать система?
  2. На основании этого дизайна ваша база данных. Вы можете использовать каркасы ORM, такие как Ibatis или Hibernate (у Ibatis есть генератор кода, который генерирует почти все DAO для доступа к таблицам. Он дает вам методы CRUD, и вы можете добавить их поверх).
  3. Как только вы закончите с этим, вы можете приступить к проектированию уровня обслуживания. Не рекомендуется выставлять DAO напрямую контроллерам (шаблон MVC). Это где ваша бизнес-логика должна войти.
  4. Выберите один из доступных веб-фреймворков. Самые популярные веб-фреймворки Java - это Spring MVC. Вы также можете попробовать Google Guice.
  5. Последним шагом будет разработка вашего внешнего интерфейса. Я думаю, что ваш проект будет включать в себя много JavaScript. Так что посмотрите в JQuery или EXT JS

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

...