VPF::в чем преимущества использования hivemind

Barvetal

Дата 12.7.2006, 13:49 (ссылка)

(нет голосов)

Загрузка ...

Бывалый

Профиль
Группа: Awaiting Authorisation
Сообщений: 181
Регистрация: 31.10.2005

Репутация: 5
Всего: 5

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

Почитал весь сайт по хивмайнд от корки до корки. Ну даст мне эта технология разделение логики по сервисам. А без хивмайнда тоже есть разделение логики, только по классам (в каждом классе своя логика). Ну не надо будет мне писать создание объекта в коде, зато нужно писать getter и делать несколько строк записи в xml-файле. Разве это упрощает разработку? Все только разносится по разным файлам.
А взять конфигурейшн пойнт. Они говорят, что удобно, что сразу все конфигурации из xml заганяются в классы. А если я буду использовать properties файлы, то у меня получение конфигурации тоже будет очень простое.

Честное слово, почитал все доки, как работает понял, а что даст на практике, не понимаю...

Объясните, пожалуйста, популярно, что мне даст использование технологии хивмайнд.

Всем заранее большое спасибо!

w1nd

Дата 12.7.2006, 21:10 (ссылка)

(нет голосов)

Загрузка ...

Вертилятор

Профиль
Группа: Завсегдатай
Сообщений: 1077
Регистрация: 22.3.2006
Где: Москва

Репутация: 7
Всего: 54

На практике вы попросту не будете писать всё это сами.

--------------------

tux

Дата 13.7.2006, 02:17 (ссылка)

(нет голосов)

Загрузка ...

Летатель

Профиль
Группа: Участник Клуба
Сообщений: 1853
Регистрация: 10.2.2005
Где: msk.ru

Репутация: 74
Всего: 132

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

Использовать или не использовать - зависит от задачи. На самом деле IoC не всегда оправдан. Рекомендую почитать статью Мартина Файлера, если не читал, конечно,- http://www.martinfowler.com/articles/injection.html.

Barvetal

Дата 14.7.2006, 13:32 (ссылка)

(нет голосов)

Загрузка ...

Бывалый

Профиль
Группа: Awaiting Authorisation
Сообщений: 181
Регистрация: 31.10.2005

Репутация: 5
Всего: 5

Позволю себе привести цитату из статьи Фаулера:

Цитата

Inversion of control is a common feature of frameworks, but it's something that comes at a price. It tends to be hard to understand and leads to problems when you are trying to debug. So on the whole I prefer to avoid it unless I need it. This isn't to say it's a bad thing, just that I think it needs to justify itself over the more straightforward alternative.

The key difference is that with a Service Locator every user of a service has a dependency to the locator. The locator can hide dependencies to other implementations, but you do need to see the locator. So the decision between locator and injector depends on whether that dependency is a problem.

Using dependency injection can help make it easier to see what the component dependencies are. With dependency injector you can just look at the injection mechanism, such as the constructor, and see the dependencies. With the service locator you have to search the source code for calls to the locator. Modern IDEs with a find references feature make this easier, but it's still not as easy as looking at the constructor or setting methods.

A lot of this depends on the nature of the user of the service. If you are building an application with various classes that use a service, then a dependency from the application classes to the locator isn't a big deal. In my example of giving a Movie Lister to my friends, then using a service locator works quite well. All they need to do is to configure the locator to hook in the right service implementations, either through some configuration code or through a configuration file. In this kind of scenario I don't see the injector's inversion as providing anything compelling.

The difference comes if the lister is a component that I'm providing to an application that other people are writing. In this case I don't know much about the APIs of the service locators that my customers are going to use. Each customer might have their own incompatible service locators. I can get around around some of this by using the segregated interface. Each customer can write an adapter that matches my interface to their locator, but in any case I still need to see the first locator to lookup my specific interface. And once the adapter appears then the simplicity of the direct connection to a locator is beginning to slip.

Since with an injector you don't have a dependency from a component to the injector, the component cannot obtain further services from the injector once it's been configured.

A common reason people give for preferring dependency injection is that it makes testing easier.
.....................

So the primary issue is for people who are writing code that expects to be used in applications outside of the control of the writer. In these cases even a minimal assumption about a Service Locator is a problem.

и ниже по коду:

Цитата

When building application classes the two are roughly equivalent, but I think Service Locator has a slight edge due to its more straightforward behavior. However if you are building classes to used in multiple applications then Dependency Injection is a better choice.

Исследуя это все, прихожу к выводу, что есть ситуации, когда IoC следует использовать, а есть ситуации, когда его использование неокупается.
Если я пишу приложение, использующее различные сервисы, и это приложение будет использоваться другими разработчиками в других командах, то однозначно IoC, чтобы те люди могли реализовывать свои сервисы.
Если приложение использует различные сервисы, но приложение будет использоваться только одной командой разработчиков, то можно использовать и Service Locator, и IoC. Но Service Locator проще, IoC красивее. Разницу большую не вижу.

Но я совершенно не вижу смысла применять IoC везде для каждого класса бизнес-логики. Например, пускай я пишу модуль для отдела кадров. Нужно реализовать прецедент приема на работу. Я не вижу смысла выносить метод приема на работу в сервис, подключаемый через IoC к некоему классу. Ведь этот метод специфичный для организации и используется только в одном месте.
То-есть, я говорю о том, что если у меня есть специфическая бизнес-логика, которая используется только в одном месте и только в моей команде, не вижу никакого смысла использовать ни Service Locator, ни IoC для убирания зависимостей между классами бизнес-логики. Единственный случай, когда я вижу смысл использовать IoC в специфическом бизнес-приложении, это использование системных сервисов наподобие подключения в приложение кеша или использование внешних источников данных.

1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема \| Java EE (J2EE) и Spring \| Следующая тема »