2006年10月04日04:00 カテゴリValue 2.0 現代というコンポーネントは、どのような未来をプログラムするのか これにならってPerlを使うべき本当の理由を述べてみましょう。 分裂勘違い君劇場 - 現代という時代は、どのようなプログラミングを求めているのか？ Rubyを使うべき本当の理由は、根源的には、日本で自殺者が増えた理由と同じです。 今後日本が没落していく理由とも同じです。 団塊の世代に無能な人間が多い理由とも同じです。 サービス残業が増えた理由とも同じです。 日本の多くの若者たちが未来に希望を抱けない理由とも同じです。 いまの学校教育が無能な人間の製造工場になってしまっている理由とも同じです。 Perlを使うべき本当の理由は、根源的には、日本が金持ちになった理由と同じです。 今後土建屋が没落していく理由とも同じです。 団塊ジュニアに有能な人間が多い理由とも同じです。

1. はじめに 皆さん、こんにちは。私はオージス総研でオブジェクト指向技術を用いたSI、コンサルティングを業務とする、プロの仕事を目指す、一介のUMLシルバーレベル1のプログラマ2です。ソフトウェア業界では、オブジェクト指向も、もはや普通の技術として認知されています。有名なマイクロソフトのVB、VC++をはじめ、現在使用している開発環境のほとんどは、すべてオブジェクト指向をサポートしているといってもよいでしょう。オブジェクト指向を知らない人でも、気が付かないうちにオブジェクト指向している、なんてこともあるようです。 でもオブジェクト指向は、単にソフトウェアをより良く作るための手段のひとつですから、上手く利用しないと、そうするつもりはなくても、とんでもないソフトウェアを作ってしまうことになりかねません。悲しいことに、オブジェクト指向は結構敷居が高いと思います。オブジェクト指向のメリットである

「Type2:Serviceに業務ロジックを書く」でも、同じようなロジックが複数のViewに分散する問題は以前未解決のままです。それを解決しようとするのがこのTypeです。 Type3:Entityに業務ロジックを書く Viewごとに業務ロジックを書けば､分散してしまう可能性がありますが､Entityにロジックを書けば､分散の危険性が減ります。なぜなら、Entityを利用するときに､既に似たようなロジックがないか探すことができるからです。 TransactionServletFilter Action(プレゼンテーションロジック) Dao(データアクセスロジック。ActionにDI) EntityManager(DaoにDI) Entity(業務ロジック) 開発者が書く必要があるのは､Action、Daoのインターフェース、Daoの実装、Entityに対する業務ロジックの実装です。 プレゼ

EJB3、JSF、JPAを使ったときのアーキテクチャは､ある一定のパターンで説明できると思っています。私見ですが､説明したいと思います。 まず、プレゼンテーション層であるJSFですが、ページ(View)ごとにManagedBean(s)を定義します。ManagedBeanの作り方は3パターンあり イベント処理専用(Action)でモデルとしてはEntity(ドメインモデル)を使う(Action only) イベント処理とプレゼンテーションモデルを兼用(Page only。Pageでイベントも処理) イベント処理(Action)とプレゼンテーションモデル(Page)を分離(Action + Page) があります。 私は､ドメインモデルは､ドメイン層でのみ使い､プレゼンテーション層では､専用のプレゼンテーションモデルを使うべきだと思っています。なぜなら、ドメイン層とプレゼンテーション層では､