Вопросы Теги

Опишите архитектуру, которую вы используете для веб-приложений Java? [закрыто]

Вы можете самостоятельно создать собственный валидатор datetime

1) создать папку, называемую валидаторами внутри каталога приложения

2) создать файл datetime_validator.rb. со следующим содержимым внутри каталога приложений / валидаторов 

 class DatetimeValidator < ActiveModel::EachValidator
  def validate_each(record, attribute, value)
    if ((DateTime.parse(value) rescue ArgumentError) == ArgumentError)  
      record.errors[attribute] << (options[:message] || "must be a valid datetime")
    end
  end
end

3) Применить эту проверку на модели 

class YourModel < ActiveRecord::Base
  validates :happend_at, datetime: true
end

4) Добавить нижнюю строку в application.rb 

config.autoload_paths += %W["#{config.root}/app/validators/"]

5) Перезапустите приложение для рельсов

Примечание: описанный выше метод протестирован в рельсах 4

143
задан user14070 13 November 2008 в 12:55
поделиться

2 ответа

Хорошо я сделаю (более короткий):

  • Frontend: Гобелен (3 для более старых проектов, 5 для более новых проектов)
  • уровень Business: дао Spring
  • : база данных Ibatis
  • : Oracle

Мы используем поддержку транзакции Sping и запускаем транзакции после ввода уровня служб, распространяя вниз к вызову ДАО. Уровень служб имеет самое бизнес-знание модели, и ДАО делает относительно простую работу CRUD.

Некоторый более сложный материал запроса обрабатывается более сложными запросами в бэкенде по причинам производительности.

Преимущества использования Spring в нашем случае состоят в том, что у нас могут быть подчиненные экземпляры страны/языка, которые находятся позади Прокси-класса Spring. На основе пользователя на сессии корректная реализация страны/языка используется при выполнении вызова.

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

Жаль это короче, чем Ваше сообщение, надежда, Вы находите это интересным...

20
ответ дан 3 revs, 3 users 79% 13 November 2008 в 12:55
поделиться
  • 1
    Я думаю, что Вы забыли инвертировать условие удаления добраться, сохраняют условие;-), но я понимаю Вашу точку, и это - (по моему скромному мнению), лучшее решение, которое я знаю на данный момент... – WildWezyr 11 January 2010 в 18:19

Мы все еще используем обычный стек Struts-Spring-Hibernate.

Для будущих приложений, мы изучаем веб-Поток Spring + Spring, MVC + В спящем режиме, или Spring + В спящем режиме + веб-сервисы с фронтэндом Flex.

А отличная характеристика нашей архитектуры является модуляризацией. У нас есть много модулей, некоторые запускающиеся с 3 к макс. 30 таблицам в базе данных. Большинство модулей состоит из бизнеса и веб-проекта. Бизнес-проект содержит логику бизнеса и персистентности, в то время как сеть содержит логику представления.
На логическом уровне, существует три слоя: Бизнес, Персистентность и Представление.
Зависимости:
Представление зависит по работе и Персистентность.
Персистентность зависит по работе.
Бизнес не зависит от других слоев.

большинство бизнес-проектов имеет три типа интерфейсов (примечание: не GUI, это - программный слой интерфейса Java).

  1. Интерфейс, который представление использует в качестве клиента
  2. Интерфейс, который используют другие модули, когда они - клиент модуля.
  3. Интерфейс, который может использоваться в административных целях модуля.

Часто, 1 расширяется 2. Таким образом, легко заменить одну реализацию модуля с другим. Это помогает нам принять различным клиентам и интегрироваться более легко. Некоторые клиенты купят только определенные модули, и мы должны интегрировать функциональность, которую они уже имеют. Так как интерфейс и слой реализации разделяются, легко развернуть реализацию модуля залога рекламы для того определенного клиента, не влияя на подчиненные модули. И Платформа Spring помогает ввести другую реализацию.

Наш бизнес-слой основан на POJOs. Одна тенденция, которую я наблюдаю, состоит в том, что эти POJOs напоминают DTOs. Мы страдаем от анемичная модель предметной области . Я не совсем уверен, почему это происходит, но это может произойти из-за простоты проблемной области многих наших модулей, большая часть работы является CRUD или из-за разработчиков, предпочитающих поместить логику где-то в другом месте.

4
ответ дан Dan 13 November 2008 в 12:55
поделиться
  • 1
    Вероятно, также зависит от того, сколько объектов Вы удаляете по сравнению с тем, сколько находится в списке, т.е. если у Вас есть список с 10 000 объектов, и только необходимо удалить 2 по сравнению со списком с 10 000 объектов, куда необходимо удалить 9,999 из них. – matt b 11 January 2010 в 18:29
Другие вопросы по тегам:

Похожие вопросы: