Comments on: Разработка веб-приложений на Spring. Часть 3 (Реализация)

By: Владимир

Владимир — Mon, 14 Jun 2010 06:35:20 +0000

Пишет, что не может найти где объявлено InviteSubscriber в классе InviteSubscriberService.java. Так где все таки оно объявляется? Надо еще какой то класс подключать, или какую то библиотеку я не подключил?

By: DS

DS — Wed, 02 Jun 2010 16:25:11 +0000

Не совсем понятно насчет класса com.allofrss.beans.form.InviteFormBean, на который ссылка в allofrss-context.xml. Вы его здесь не описали почему то.

By: Maks

Maks — Tue, 27 Apr 2010 18:26:14 +0000

Неплохо было бы “извлечь” интерфейсы у DAO и Service сущностей. Такой подход более привычный для Spring-а.
И, возможно я не прав, но в вашем случае иметь отдельные классы данных для форм и для Hibernate entity не слишком “‘экономное” решение.
А по поводу оформления – код ну очеень трудно читается. Может вот это поможет решить это неудобство http://alexgorbatchev.com/wiki.....ter:Usage.

By: Nick

Nick — Mon, 10 Mar 2008 11:46:10 +0000

>>методы содержащиеся в классе расчитаны по умолчанию
раcсчитаны

By: Олег Евгеньевич.

Олег Евгеньевич. — Fri, 07 Mar 2008 15:02:17 +0000

Да я немного прочитал ещё по этой связке, и осознал всю прелесть 1 единственного ApplicationServiceManager-а (можно сделать для удобства интерфейс), в котором сосредоточена вся бизнес-логика (или логика полученя данных). И просто как пропертю передавать этот менеджер в контоллер, далее на страничку. Все сведется к простой проверке правильности выполнения эти сервисов, и переход на соответствующую страничку согласно сценарию. Уровень бизнес-логики становится интуитевно понятнее и ближе к теоретическому описаний его функциональности. Про DataSource вопрос снимаю – разобрался. Буду ждать более глубоких ваших размышлений.

By: Андрей Ясинецкий

Андрей Ясинецкий — Fri, 07 Mar 2008 13:31:27 +0000

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

По поводу нескольких датасорсов, но ведь и в моей реализации число датасорсов не ограничивается. Просто делаете несколько sessionFactory с разными датасорсами вот и всё… Если я правильно понял

By: Олег Евгеньевич.

Олег Евгеньевич. — Wed, 05 Mar 2008 11:30:29 +0000

Да забыл добавить, вы просто не внесли ни одного маппинга доменных объектов, могут возникнуть вопросы. Я бы описал пару объектов, с маппингами. Всё таки мне кажется, что вы не полноценно используете DAO, так как с помощью TransactionProxyFactoryBean можно настроить DAO на любой DataSource, при этом просто реализовав соответствующий интерфейс.

By: Олег Евгеньевич.

Олег Евгеньевич. — Wed, 05 Mar 2008 11:07:31 +0000

Здравствуйте, да написано коротко и ясно, но всегда возникает следующий вопрос. Мы рассмотиваем всё на уровне единственной реализации DAO с минимальным (simple) количеством методов, Хотелось бы посмотреть реализацию сразу нескольких DAO, с полным конфигурированием через struts. То есть по всем правилам паттерна DAO, с созданием интерфейсов, имплементацией этих интерфейсов, с использованием TransactionProxyFactoryBean. Если поможете разобраться буду признателен. Спасибо

By: Андрей Ясинецкий

Андрей Ясинецкий — Wed, 27 Feb 2008 13:08:48 +0000

Да, для приведённого тут примера в принципе не нужны. Мне возможно стоило это опустить, но в принципе в AllOfRss он всё равно присутствует, так-как там будет как-раз тот случай, о котором ты написал.

By: Mr.K

Mr.K — Wed, 27 Feb 2008 12:53:50 +0000

А вот тут не соглашусь с тобой на счет того, что иметь слой служб – это архитектурно правильнее. Все зависит от конкретного приложения. Если у тебя работа с серверное частью, например, идет как напрямую через веб-часть, так и через RPC (Corba или там SOAP/XML-RPC) — тогда слой служб необходим, чтобы не дублировать один и тот же код в разных местах. Если же у тебя всегда одно представление — слой служб будет просто бюрократией.