|
|
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪ, неверно, для веба так Код: java 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2011, 12:40:06 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪВ вашем коде используется PROPAGATION_REQUIRES_NEW. Вы не могли бы привести пример, зачем PROPAGATION_REQUIRES_NEW бывает нужен? Мне никогда не встречалась необходимость его использовать.Пример из жизни. Веб приложение, пользователь кликает на кнопку и запускает длительный процесс. Процесс может завершиться успешно, может свалиться с ошибкой - . При этом пользователь хочет видеть прогресс выполнения. 1) Открывается транзакция, запускается процесс - PROPAGATION_REQUIRED 2) Пишем в базу запись о начале процесса - упрощенно INSERT (id, start_date) - PROPAGATION_REQUIRES_NEW 3) Идет выполнение процесса, какое-то взаимодействие с базой, какая-то незакоммиченная информация 4) Через некоторые интервалы пишем в базу статус выполнения процесса - упрощенно UPDATE completed = 5/10 WHERE id - PROPAGATION_REQUIRES_NEW 5) Дальше выполняем, какое-то взаимодействие с базой, какая-то промежуточная незакоммиченная информация в базе 6) Эксепшн, вылетаем, всяе промежуточное откатывается. По итогам - пользователь видит, что процесс оборвался на таком-то этапе, но база в целостном состоянии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2011, 12:48:32 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
автор3) Эта фича полезна при тестировании и при развертывании приложения в разных окружениях. Вот у меня дефолтная конфигурация для WebSphere, а вот у меня импорт, который заменяет JNDI ресурсы на локальные, а вот у меня импорт, который позволит работать на WebLogic - например, подменяет TransactionManager. Значит, чтобы действовал определенный импорт, остальные надо удалить или закомментировать? Если мне надо деплоить приложение на WebLogic и WebSphere, то я скорее всего захочу написать пару скриптов deploy_to_web_sphere.bat и deploy_to_weblogic.bat, потому что каждый раз править руками applicationContext.xml очень неудобно. Как мне написать такие скрипты? Придется делать препроцессинг applicationContext.xml? Теперь представьте себе, что в apllicationContext.xml разрешены условные конструкции: Код: xml 1. 2. 3. 4. 5. 6. Скрипту останется создать файл server.properties: Код: xml 1. Такой способ я считаю нормальным. Но он требует нормального языка, который по крайней мере поддерживает if'ы. Так как засунуть такой язык в XML - явное безумие, выход один - не пользоваться Spring XML, а создавать бины сразу в Java. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2011, 13:31:36 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪЕсли мне надо деплоить приложение на WebLogic и WebSphereа надо, да? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2011, 13:37:19 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
Если мне надо деплоить приложение на WebLogic и WebSphere а надо, да? svenom пишет, что ему надо: Вот у меня дефолтная конфигурация для WebSphere, а вот у меня импорт, который заменяет JNDI ресурсы на локальные, а вот у меня импорт, который позволит работать на WebLogic ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2011, 13:39:26 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪЗначит, чтобы действовал определенный импорт, остальные надо удалить или закомментировать?Варианты: 1) Поменять имя подхватываемого XML-файла руками 2) Нужные файлы контекста можно подсунуть через Ant/Maven 3) Можно сделать через файл свойств и промежуточный XML-ник 4) Еще есть какой-то вариант с EagerPropertyPlaceholderConfigurer, но я тут деталей не знаю. Йуный джавистЪвыход один - не пользоваться Spring XML, а создавать бины сразу в JavaМне жаль, что единственный для вас выход решить проблему, которая заключается в отсутствии проблемы, - изобрести велосипед. Приведите пример, как вы будете "создавать" бины в Java. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2011, 13:50:56 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪ , И вы как-то плавно с темы транзакций съехали. Чем меня прикалывают длинные вот такие длинные дискусии, так тем, что оппоненты, как правило, предпочитают забывать про свои спорные утверждения и не отвечать на вопросы, которые явно поставят их в невыгодное положение, а вместо этого продолжают заваливать меня вопросами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2011, 13:53:40 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪТеперь представьте себе, что в apllicationContext.xml разрешены условные конструкции: Такой способ я считаю нормальным. Но он требует нормального языка, который по крайней мере поддерживает if'ы. Так как засунуть такой язык в XML - явное безумие, выход один - не пользоваться Spring XML, а создавать бины сразу в Java.в новом 3.1 разрешены - смотри profile if в конфигурации плохо. конфиг не должен быть ЯП, по крайней мере в идеале. PS никто не мешает создавать бины в Java и отдавать в Spring. Можно даже всю конфигурацию держать в виде java кода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2011, 14:00:59 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
Приведите пример, как вы будете "создавать" бины в Java. Приводил пример в первом посте в этом треде. Насчет транзакций - я как раз собираюсь написать пост о них. Просто сначала решил ответить на другой вопрос. Если бы форум был древовидным, то все было бы удобнее. предпочитают забывать про свои спорные утверждения Каждое свое утверждение я подкрепляю какими-то аргументами, примерами кода, объяснениями. Ваши посты часто состоят из одного - двух слов и смайликов, например: авторОк, не вопрос. авторВам виднее авторВсе может быть авторГолословщина. Это уже говоря о том, что вы отправляете меня читать документацию, которую я читал, а вы нет, потому что от нее "пухнет голова". Так что не надо делать мне замечания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2011, 14:10:57 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
VoDA, авторникто не мешает создавать бины в Java и отдавать в Spring. Можно даже всю конфигурацию держать в виде java кода. Я так и делаю, только Spring IoC не использую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2011, 14:14:28 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪПриводил пример в первом посте в этом треде.Помню, помню, велосипед. Все уже давно написано и отлажено за вас. Зачем тратить время на повторное набивание шишек - непонятно. Йуный джавистЪКаждое свое утверждение я подкрепляю какими-то аргументами, примерами кода, объяснениями.Дак речь про то, что на те мои посты, где вам есть, что опровергнуть, вы отписываетесь с удовльствием. А вот те посты, на которые ответить негативного нечего, остаются без внимания Йуный джавистЪВаши посты часто состоят из одного - двух слов и смайликов, напримерВы про вот эти: 11761662 , 11768047 , 11768086 , 11768157 , 11768191 , 11770239 , 11770334 , 11770865 ? Это все, что я вам отвечал, односложных постов я там не увидел, все по делу, с разжевыванием. Есть односложные ответы на комментарии, которые основываются либо на вашем негативном опыте работы с чем-либо (читай - "не смог разобраться"), либо же на додумках, вроде: Йуный джавистЪВ Java нормальные средства декомпозиции, а в Spring XML - кривые.Вам виднее - народ пользуется, не жалуется особо. Хотите - XML, хотите - аннотации. Как говориться, на любой вкус. Если вы не смогли с ними совладать, то это означает только то, что вы не смогли с ними совладать. Сам продукт это никак не характеризует. Йуный джавистЪЕсли для описания конфигурации полноценный язык не нужен, то зачем тогда надо было делать Spring EL? Мне кажется, через пару лет разрешат вставлять в XML файлы куски кода на нормальных языках и конфигурировать бин с названием codeEvaluator, который наследует от AbstractCodeEvaluatorFactory, и у которого из коробки три реализации - JavaCodeEvaluatorFactory, JavaScriptCodeEvaluatorFactory и еще какой-нибудь GroovyCodeEvaluatorFactory.Все может быть - что тут можно еще ответить? Йуный джавистЪВ нескольких мегабайтах библиотек содержатся тысячи багов и граблей (см пример выше).Голословщина - она и есть голословщина. Весь Java-мир построен на open-source библиотеках, и все нормально работает. У одного вас какие-то мифические тысячи багов отовсюду лезут У меня сейчас приложение - 35 метров еарник, и это мы еще потрудились, что бы его урезать, был около 60. Проработал уже 4 года без проблем. Что мы делаем не так? Что нужно сделать, что бы наткнуться на эти тысячи багов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2011, 15:27:48 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪ , Можно даже сделать приблизительную оценку количества багов в моем текущем проекте. 1) Если в нескольких мегабайтах кода содержатся тысячи багов (цитирую вас), то давайте остановимся на умеренной оценке 1 мегабайт = 1000 багов. 2) То есть в моем приложении сейчас примерно 35000 тысяч потенциальных багов. 3) Чисто нашего кода, который профессионально оттестирован, либо же сгенерирован - примерно 10 метров. Считаем, что там багов нет или почти нет. Остается 25000 багов в сторонних библиотеках. 4) Пускай из сторонних библиотек используется в среднем только 1% их функционала. Получается, что мы должны постоянно сталкиваться с 350 багами той или иной критичности. Что-то я их пока в таком количестве не вижу. Нет, я помню забавный баг(скорее недоработку) в Хибере, который выдает невнятное сообщение об ошибке в определенных случаях; я помню баг в Rampart, когда вылетал NullPointerException; я помню баг в JVM веб-сферы, когда она не могла через рефлекшн найти метод (вылечилось установкой фикспака) ... но вот где остальные 347? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2011, 15:36:59 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
Исправление: не 350 и 347, а 250 и 247 соответственно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2011, 15:37:53 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
параметры присоединения/открытия (Requires, RequiredNew, Supported, Mandatory и т.д.) В 99.99% случаях запрос обрабатывается так: открывается транзакция, делается вся работа, транзакция закрывается. Не надо никакого xml, не надо генерировать и загружать код в рантайме, не надо засорять стэк вызовов. Вот пример из документации спринга: public Object someServiceMethod() { return transactionTemplate.execute(new TransactionCallback() { // the code in this method executes in a transactional context public Object doInTransaction(TransactionStatus status) { updateOperation1(); return resultOfUpdateOperation2(); } }); } Теперь для всего кода внутри someServiceMethod будет propagation=Requires. В случае с Hibernate и web-интерфейсом в транзакцию надо заворачивать вообще весь сервлет (из-за lazy loading в шаблонизаторе). То есть просто навешиваем servlet-фильтр на все и дальше не паримся. Вообще, spring transactions почти нормальная библиотека (совершенно отдельная от spring ioc). Единственная претензия - разработка требует огромной внимательности. Очень легко допустить ошибку, которую не выявят никакие тесты. Пример: Код: java 1. 2. 3. 4. 5. Разработчик пишет такую функцию, и забывает завернуть ее в транзакцию(неважно как - через @Transactional, через xml либо через такое API как выше). В результате оба запроса выполняются с autocommit=true, что очень печально. В том API, которое я описывал ранее в этом треде 11767978 , если мы забываем открыть транзакцию, при попытке выполнить sql запрос просто вылетит exception, что не позволяет допустить глупую ошибку. Еще бывают автономные транзакции, но они нужны крайне редко. Если все таки нужны, то можно написать как то так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Если бы было много функций, которые можно выполнять как в текущей транзакции, так и в отдельной, то такая писанина конечно быстро бы надоела. Но так как это бывает нужно крайне редко, то все ок. Ну и напоследок, если все таки хочется совсем как в Spring, то xml все равно не нужен: It is also possible to use the Spring Framework's @Transactional support outside of a Spring container by means of an AspectJ aspect. To use this support you must first annotate your classes (and optionally your classes' methods with the @Transactional annotation, and then you must link (weave) your application with the org.springframework.transaction.aspectj.AnnotationTransactionAspect defined in the spring-aspects.jar file. То есть AspectJ во время сборки добавляет в методы, помеченные @Transactional возню с transactionTemplate. Spring IoС здесь банально не нужен для AOP, как я уже отмечал в 11767978 . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2012, 23:53:59 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪВ 99.99% случаях запрос обрабатывается так: открывается транзакция, делается вся работа, транзакция закрывается. Не надо никакого xml, не надо генерировать и загружать код в рантайме, не надо засорять стэк вызовов.Что любопытно - вы так и не поняли, что значит декларативное управление транзакциями и в чем его преимущество по сравнению с программным. Поэтому нет никакого смысла комменитровать вашу дальнейшую писанину ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2012, 00:01:21 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
Что любопытно - вы так и не поняли, что значит декларативное управление транзакциями и в чем его преимущество по сравнению с программным. Ну, собственно, я даже не знаю что это такое. Википедия ничего об этом не знает. В гугле большинство ссылок ведет на спринг, но Spring документация подразумевает, что это понятие уже известно читателю. По поводу преимуществ - все что я нашел в документации к Spring о преимуществах, это следующее: Most users of the Spring Framework choose declarative transaction management. It is the option with the least impact on application code, and hence is most consistent with the ideals of a non-invasive lightweight container. Ну то есть преимущество в том, что это соответствует идеалам. С такой же мотивацией можно вставлять в код цитаты из Ленина, потому что это соответствует идеалам борьбы за коммунизм. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2012, 00:17:17 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
Ок, давайте проще попробуем. В чем смысл AOP понимаете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2012, 00:21:39 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
Ок, давайте проще попробуем. В чем смысл AOP понимаете? Вы лучше укажите, чем плох описанный мной подход. Либо киньте ссылку на ресурс, где описываются преимущества декларативного управления транзакциями в Spring. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2012, 00:36:13 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
Что бы понять, чем плох ваш подход вам надо понять, для чего нужен AOP, потому я и спрашиваю у вас - понимаете вы, для чего он нужен или нет. И тут не идет разговор про декларативные транзакции в спринге , разговор идет про декларативные транзакции в принципе . Так вот, есть такое понятие, как separation of concerns, которое гласит нам, что мухи должны быть отдельно, а котлеты отдельно. AOP это одно из развитий этой идеи. Эта идеаология гласит - есть бизнес логика, а есть вспомогательная, скажем так - инфраструктурная логика, и они должны быть разделены. Основная мотивация - легкость в восприятии, легкость в поддержке, легкость в разработке. Декларативные транзакции - одна из реализаций идеи AOP (другие примеры - фильтры сервлетов, управление авторизацией и аутентификацией, интерсепторы в EJB - это все чистый AOP). Когда мы управляем транзакциями декларативно, у нас появляется возможность сфокусироваться на бизнес-логике, и не морочить себе голову одинаковым повторяющимся вспомогательным кодом, которым будет засрана всяе бизнес-логика. На выходе у нас получается чистая бизнес-логика без каких-либо зависимостей от менеджера транзакций. Что бы вам было проще представить это, давайте возьмем пример из реальной жизни. Представьте себе, что вы директор, который идет в свой офис, и ожидает там через несколько часов каких-то людей для переговоров. Вы хотите быть уверенным, что когда они придут, ваш кабинет будет чистым, будет достаточно канцелярских принадлежностей и вас не будут отвлекать звонками. Вот вариант, как этого можно добиться без AOP: - попросить уборщицу протереть полы в кабинете - попросить офис-менеджера принести канцелярские принадлежности - попросить секретаря, что бы вас не беспокоили - принять партнеров - сказать секретарю, что вас уже можно "беспокоить" То есть вам надо было только принятб партнеров, а вам вместо этого еще потратить время на кучу вспомогательных действий. А вот вариант с использованием AOP: - принять партнеров Все. Все остальные действия сделаны за вас, так как: - Аспект "уборщица" знает, что при наступлении события "7 утра" надо "протереть полы в офисе" - Аспект "офис-менеджер" знает, что при наступлении события "понедельник четной недели" надо "принести канцелярские принадлежности" - Аспект "секретарь" знает, что при наступлении события "в кабинете директора появились посторонние", надо перейти в режим "нельзя беспокоить", а при наступлении события "в кабинете директора больше нет посторонних" перейти в режим "можно беспокоить". Вот вам как было бы комфортнее работать - по первому или по второму сценарию? При этом, естественно, за все надо платить. И платой за использование AOP является дополнительный оверхед на динамические прокси, на рефлексию и т.д.. Но от этого никуда не деться, в программировании, как и в любых других дисциплинах действует адаптированное золотое правило механики - выиграли в одном, проиграли в другом. И готовы ли вы пойти на этот дополнительный оверхед зависит исключительно от разрабатываемой системы. В большинстве случаев мы можем пойти на это, потеряв несколько десятков микросекнуд. А в каком-нибудь крайнем случае, это может быть невозможно. И это абсолютно естественно - у каждой технологии есть свои границы применимости. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2012, 00:56:10 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪ, да нет осбых Явных преимуществ. Кому-то нравится управлять кодом, кому-то расставлять аннотации. В модели среда контейнера заботится о запуске, фиксации и окате транзакций. Разработчик отвечает только за указание поведения транзакции. В первых двух он это делал так: старт f1() f2() f3() откат \ commit в декларативной он пишет аннотацию и кучу флагов. Код: java 1. 2. Кому что больше нравится. Хочу обратить внимание: - очерёдность и события не относятся к декл.транз. - надо строго знать модель, стратегию и атрибуты аннотаций. То что ты писал в коде, теперь надо будет расставлять "флажками". - При использовании модели декларативных транзакций контейнер не будет автоматически откатывать транзакцию в случае проверяемого исключения. Разработчик должен указывать, где и когда откатывать транзакции в случае проверяемого исключения (rollbackFor). Т.е. пока вы не определитесь со стратегией и моделью хотя бы на пакет действий С ОТКАТАМИ БИЗНЕС-ТРАНЗАКЦИИ, ВЫ НЕ ПОЙМЁТЕ ПРЕИМУЩЕСТВА ДЛЯ ДАННОГО ПРОЕКТА. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2012, 01:48:56 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
Svenom, AOP на джаваскрипте делается в 10 строчек: Код: javascript 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. Можно скопировать в htm и открыть в браузере. Результат работы такой: Код: javascript 1. 2. 3. 4. 5. 6. Сравните - в Java надо иметь несколько Mb библиотек, какой-то мутный XML, генерировать и подгружать код в рантайме. В Javascript вообще не надо библиотек, все делается в 10 строк. Создатели языков не добавляют такие возможности в языки потому что их использование - очень плохая практика. Глядя на код, невозможно понять откуда к нам пришел какой-то объект, какие аспекты на него навесили. В дебагере вообще будет адский ужас - код без исходников, либо код с исходниками, который поковыряли после компиляции. Возможно, в каких-то крайних случаях приходится идти даже на такое. Но управление транзакциями - это явно не тот случай. авторТак вот, есть такое понятие, как separation of concerns, которое гласит нам, что мухи должны быть отдельно, а котлеты отдельно. AOP это одно из развитий этой идеи. Эта идеаология гласит - есть бизнес логика, а есть вспомогательная, скажем так - инфраструктурная логика, и они должны быть разделены. Вообще я вижу смысл отделять инфраструктурную логику, только если предполагается, что в разных случаях она разная, и ее можно подцепить или отцепить. Если же вместе с какой-то функцией ВСЕГДА идет эта инфраструктурная логика, то отцепляя ее, мы усложняем на ровном месте. Когда я работаю с базой, я всегда делаю это в рамках какой-то транзакции. Кстати Svenom, вы понимаете, что в таком примере: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. если мы запроксируем функцию c(), а функции a() и b() оставим как есть, то при вызове функции c() все три функции a,b и c будут выполняться в одной транзакции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2012, 03:54:18 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪСравните - в Java надо иметь несколько Mb библиотек, какой-то мутный XML, генерировать и подгружать код в рантайме. В Javascript вообще не надо библиотек, все делается в 10 строк.Сравнил, какой я должен сделать из этого вывод? Йуный джавистЪСоздатели языков не добавляют такие возможности в языки потому что их использование - очень плохая практика.Ах вооот оно как А я то думал, что в Java так сделать нельзя, так как это язык со строгой типизацией и в нем нельзя передавать функцию в качестве параметра , а на самом то деле вон оно как оказывается - это потому что AOP очень плохая музыка практика. Кстати, то, что вы написали, это нe AOP, а говнокод, уж извините, так как он абсолютно нерасширяемый и неподдерживаемый. Йуный джавистЪГлядя на код, невозможно понять откуда к нам пришел какой-то объект, какие аспекты на него навесили.Совершенно верно, именно это и является целью введения AOP - что бы бизнес-логика не была засорена вспомогательным сервисным кодом. Вы только что сами проговорили одно из основных преимуществ AOP. Йуный джавистЪВ дебагере вообще будет адский ужас - код без исходников, либо код с исходниками, который поковыряли после компиляции.Это ваша додумка. А все потому, что вы даже не удосужились разобраться, как работает AOP в том же спринге. 1) Исходники того, что вы сами написали, есть всегда, и их всегда можно дебажить 2) "Ковыряние" идет не в вашем классе, а во вспомогательной проксе. Ваш же класс никто не трогает. Одним словом, классический клинический случаи - слышал звон, да не знаю, где он. Йуный джавистЪВозможно, в каких-то крайних случаях приходится идти даже на такое. Но управление транзакциями - это явно не тот случай.Безусловно. Йуный джавистЪВообще я вижу смысл отделять инфраструктурную логику, только если предполагается, что в разных случаях она разная, и ее можно подцепить или отцепить. Если же вместе с какой-то функцией ВСЕГДА идет эта инфраструктурная логика, то отцепляя ее, мы усложняем на ровном месте. Когда я работаю с базой, я всегда делаю это в рамках какой-то транзакции.Умываю руки. Поработаете в серьезных проектах - поймете. Ну и, напоследок, повторю еще разок места где вы уже используете AOP: 1) Servlet - фильтры 2) Servlet - всевозможные листенеры на создание контекста, сессию и т.д. 3) Servlet - безопасность 4) JPA/Hibernate - Lazy-инициализация 5) EJB - интерсепторы 6) EJB - безопасноть Это то, что сходу в голову пришло. То есть весь JavaEE насквозь пронизан концепциями AOP, а тут выясняется, что AOP - это "очень плохая практика" Да будет так. Йуный джавистЪКстати Svenom, вы понимаете, что в таком примере, если мы запроксируем функцию c(), а функции a() и b() оставим как есть, то при вызове функции c() все три функции a,b и c будут выполняться в одной транзакции.Разумеется. Только это вы к чему? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2012, 09:29:46 |
|
||
|
Какие приемущества использования IoC контейнера?
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪВообще я вижу смысл отделять инфраструктурную логику, только если предполагается, что в разных случаях она разная, и ее можно подцепить или отцепить. Если же вместе с какой-то функцией ВСЕГДА идет эта инфраструктурная логика, то отцепляя ее, мы усложняем на ровном месте. Когда я работаю с базой, я всегда делаю это в рамках какой-то транзакции. да, в случаях с транзакциями, логика кода очень переплетена с с ними. Если это не банальный Crud на автокоммите. Поэтому выделить девственно чистый код БЛ без транзакционной обработки (if невышло to откат) - нонсенс. Так сказать POJO БЛ :). Спринг даёт выбор, и замечательно. Никто не сказал, что транзакции, это НЕ БЛ, или какая то техническая прослойка. IMHO, подозреваю, что одно из направлений Jav'ы вместе с БД хочет вынести из своего кода и TranXXX куда подальше :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2012, 11:42:12 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=37577538&tid=2132896]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
46ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 345ms |
| total: | 481ms |

| 0 / 0 |
