-
- いいね！16
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
O/R MapperとりわけActiveRecordによって、Model/Entityの区別がつかない人ってのが増えたうえに意味不明な思い込みでMVC批判してみたりとかMVACとか言い出してる状況に名前をつけたいな。
2011-03-20 15:46:58
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
Entityとは、システム設計上のデータの一塊としての実体をさしていて、DBのRowとは本質的には無関係。ModelはMVCパターンにおいて、Controllerからeventをうけとり、Viewに修正を通知するインタフェースであり、実装としてビジネスロジック/ドメインを持ってる
2011-03-20 15:50:23
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
簡単のためにEntity = Row = Modelとして動的言語によってCoC的なアプローチでリレーショナルデータベースと密結合しているO/R MapperのフレームワークあるいはパターンをActive Recordと読んでいる。
2011-03-20 15:53:09
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
一定規模以上のアプリケーションではEntity = Row には限界があるので、ActiveRecordパターンからDataMapperパターンをつかうのが自然。
2011-03-20 15:55:45
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
ActiveRecordフレームワークとActiveRecordパターンの違いは、「CoCによって、クエリを自動生成してくれたりする」というO/Rマッピングはパターンには含まれていないということ。あくまでRow = Entity = Modelという割り切りまでがパターン。
2011-03-20 15:59:45
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
そのため、ActiveRecordフレームワークのみをみて、O/R Mapperは柔軟性が低く、適切なクエリ最適化は出来ないと見切るのも誤りだし、ActiveRecordに複数のRowを操作する能力がないから、Modelとは別の層が必要だという主張も誤り。
2011-03-20 16:02:46
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
このような誤解が広がるのもひとえに、ActiveRecordフレームワークの簡便性、開発のAgilityにつながり、他のO/R Mapping機構に比べて圧倒的に覚える事が少ないというのが理由だとおもう。ちょっとしたアプリケーションを作るにあたってこの仕組みは便利。
2011-03-20 16:09:06
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
だが、これだけ簡単だというからには落とし穴が当然ある。それはビジネスモデル層が実装に依存し、決定的に密結合になるということ。
2011-03-20 16:12:01
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
で、MVACといっているものは何かっていう話になるんだが、Modelの限界として、領域の異なる複数のModelからデータを取得、表示などの機能に関して一定の境界をもうけたいというニーズがあったりする場合にそれらを集約する層としてApplicationを設けるという話。
2011-03-20 16:39:04
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
これは一般にはService層と呼ばれている事が多い。Service層は、システム境界にDTOを設けてその後ろ側の別ドメインとやりとりするためのものだ。
2011-03-20 16:40:48
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
このService層はそのService層を利用するアプリケーションにとって、何に相当するかといえば、Web APIやRDBなどのDataSource層と透過だということだ。つまり提供する側にとってはModelより外側で、提供される側にとってはModelより後ろ側であるということ
2011-03-20 16:43:59
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
重要な事はDBの境界を越えているから、Service層を使うのではなく"設計上のドメイン"を超えているから、Service層としてその操作を切り出すということ。そしてMVCの大枠にはあまり影響のあることではないということ。
2011-03-20 16:49:36
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
Service層によって、Domainを操作して、Plainなオブジェクトに変換される場所が用意された。ドメインモデル貧血症を避ければService層は薄皮の層になる。この部分にAPIとして十分な認証機構をつけたりすれば、Ajaxアプリ向けのDataSourceになる。
2011-03-20 21:02:48
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
RIAにはRIAのMVCが存在しているので、Modelがある。ということは当然DataSourceもあるのだが、これがサーバアプリケーションにとってのService層になる。
2011-03-20 21:10:32
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
そんなわけで、実はMVCとService層を設ける事が同一軸上の問題ではない。Service層は単純にシステム境界であって、アプリケーションがMVCでつくられているか,PACで作られているかは関係ない。
2011-03-20 21:17:04
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
MVC、PACへテロで構成されたいくつかのアプリケーションがあってそれをService層の境界でアグリゲートして一つのMVCアプリケーションにしてもいいし、Serviceがビジネスロジックが表現できているように振る舞えば、後ろ側が単純なTransactionScriptでもよい。
2011-03-20 21:19:13
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
ただ、PACからするともう既にすべてが協調するエージェントなので、Service層といったことは特段意識する必要がないんだけど。
2011-03-20 21:22:40
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
ServiceをDataSourceとしてとらえる考え方は実はそんなに珍しいものじゃない。たとえばPaaSなんかはDataSourceそのものをServiceとして提供しているし、ソーシャルゲームなんかはplatformの提供するapiをDataSourceにしているし。
2011-03-20 21:30:24
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
以上、おわり。こういったことはPoEAAとソフトウェアアーキテクチャとかに載ってるのであとは、それ読んでくだしあ。
2011-03-20 21:34:26
広木 大地/ エンジニアリング組織論への招待
@hiroki_daichi
MVACっていってる人の中にMMVCの話してる人もいるな。これはまたちょっと違う話。
2011-03-20 22:03:42