38617


MVCモデルに則り、Webアプリケーションを作成しようと試みております。

多くの情報をまとめますと、以下のように考えられます。

> ・ビジネスロジックはModel側に記述する  
>  ・ViewではModel側のデータを参照する形にする  
>  ・ControllerはModelやViewを介在する形で処理を割り振る

また、エビデンスのない情報ではございますが、以下の情報もございます。

> ・Viewでビジネスロジックを持たせる  
>  ・Viewは画面出力を軸とした役割のほかに、画面を介さずとも出力するならばデータ整形を担う

MVCモデルに関して現時点においてはこれが一番正しそうだ、といった情報やアドバイス・知見はございますでしょうか？


CC BY-SA 3.0
2017-10-11T01:44:24.193
38576
2017-10-12T02:10:13.160
24207
question
mvc
MVCモデルにおけるビジネスロジック


MVCモデルは非常に抽象化された(一般的な)モデルなので、どこにどのような処理機能を持たせるのかといった構築するシステムの個々の(様々な)事情が影響するような事項に関して、「一番正しそう」などという知見は存在しないと考えるべきです。

「一番正しそう」が存在しうるのはシステムの要求仕様が固まってからです。  
要求仕様が判らない(そもそもの問題が設定されていない(少なくとも質問では明らかでない)）状態では、何が正しいかも判りませんから。

また、処理機能（近視眼的ビジネスモデル）をM,V,Cのいずれか一か所に置かなければならないという考えも改めるべきです。M,V,C,いずれもコンピューティングシステムで実現する訳ですから、適切な機能を適切なモジュールで実現するのがベストプラクティスかと思います。

[ビジネスロジック (business logic)](http://wa3.i-3-i.info/word13666.html)
のような解説記事をいろいろ読んでみることをお勧めします。


CC BY-SA 3.0
2017-10-11T05:44:34.493
38588
2017-10-11T05:44:34.493
217
38576
answer


> ・ビジネスロジックはModel側に記述する  
>  ・ViewではModel側のデータを参照する形にする  
>  ・ControllerはModelやViewを介在する形で処理を割り振る

Webアプリケーションの設計手法で言うところのMVCはおおむね認識の通りかと思いますが、古典的MVCの定義から外れているのでそれはMVCではない、別の名称で呼ぶべきという主張もあります。「一番正しそう」といっても、多くの人がそう考えている、とか、多くの本にはそう書いてある、程度で、GoFのデザインパターンのように明確な定義があるわけではありません。

なので、あまり定義にこだわると永遠にアプリケーションを作り始めることはできません。

そのような呼び名が正しいかはさておきビューとコントローラとモデルの区別が不十分なプログラムは簡単にスパゲティになるというのは経験的な事実ですので、それらの役割分担を明確にしてそれを踏み越えたところにコードを書かないというポイントを意識しておけばいいのではないでしょうか。


CC BY-SA 3.0
2017-10-12T02:10:13.160
38617
2017-10-12T02:10:13.160
5793
38576
answer