|
||||||||||||
| 前のページ 1 2 3 4 | ||||||||||||
| Geronimo | ||||||||||||
|
GeronimoはASF(http://geronimo.apache.org/)で開発されているJ2EE対応のアプリケーションサーバです。DIコンテナというよりはアプリケーションサーバとして開発されていますが、DIを利用したJ2EEに対応したアプリケーションサーバとして、非常に注目されている技術ですので合わせて紹介します。 Geronimoが提供するDIの機能としては、JMX(注)のMBeanを拡張したGBeansに他のコンポーネントと依存性を持つことにあります。よってGeronimoを使って業務ロジックに他のコンポーネントにDIしていくというよりは、Geronimoを使うことでMBeanの開発をDIの仕組みを使って効率的に行っていくという使い方のほうが多いのかもしれません。
※注:
JMXとは、ネットワーク上のハードウェアやソフトウェアを監視するための仕組みで、MBeanは実際に監視を行うコンポーネントです。
|
||||||||||||
| ちなみにGeronimoではAOP機能は提供されていませんが、外部プロダクトとしてAOPの実装を導入することでAOPをつかうことは可能です。 |
||||||||||||
| まとめ | ||||||||||||
|
最後に今回のまとめとして、DIxAOPコンテナを用いたビジネスロジックをPOJOで開発した場合のメリットを考えてみましょう。 筆者の考えではテストのしやすさが一番のメリットだと思います。POJOではないオブジェクトの開発の難しさは、一度でもコーディングやテストをしたことがある人ならわかると思いますが、簡単なメソッドのテストをするだけでも、様々なテストツールの導入を考えたり、環境に依存したテストデータを用意したり、できたコードをコンテナにデプロイしたりと実際のテスト作業以外に時間がとられ、「テスト=めんどくさい、楽しくない」という図式が頭の中にできあがり、モチベーションとともに生産性・品質までもが低下してしまいます。 しかしPOJOで開発したオブジェクトは、フレームワークにもコンテナにも何にも依存しないただのJavaのオブジェクトでので、開発環境(Eclipseなど)さえあれば、コンテナにデプロイする必要もありませんし、環境に依存したテストデータを作る必要もなく、簡単に、楽しくテストができるようになるのです。 また、コードを追うにもサーブレットやEJBの操作を覚える必要もなく、純粋なJavaのプログラマであってもコードを追うことができようようになるため、コードの可読性もあがります。 POJOを容易に実現できるDIxAOPコンテナを是非一度、皆さんのプロジェクトに導入されてみてはいかがでしょうか。 |
||||||||||||
| 次回 | ||||||||||||
|
次回はオブジェクト指向とRDBとのインピーダンスミスマッチを解決するO/Rマッピングフレームワークをいくつか紹介します。 |
||||||||||||
|
前のページ 1 2 3 4 |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||

