同じプロジェクトで ASP.NET MVC と ASP.NET Web API を使用しています。これらのモデルを別々に保持するか (つまり、MVC モデルを「Models」フォルダーに配置し、Web API モデルを「ApiModels」フォルダーに配置する) かどうかを検討しています。
私はこれをするべきですか(しませんか)?それらを分離すると問題が発生する可能性はありますか? それらをまとめて、MVC と Web API の両方に同じモデルを使用すると、問題が発生しますか?
同じプロジェクトで ASP.NET MVC と ASP.NET Web API を使用しています。これらのモデルを別々に保持するか (つまり、MVC モデルを「Models」フォルダーに配置し、Web API モデルを「ApiModels」フォルダーに配置する) かどうかを検討しています。
私はこれをするべきですか(しませんか)?それらを分離すると問題が発生する可能性はありますか? それらをまとめて、MVC と Web API の両方に同じモデルを使用すると、問題が発生しますか?
Should I (not) do this?
I have to agree with both codehunter and HollyStyles. It depends, but you should tend to lean towards "keep them separate".
Could separating them cause problems?
Not necessarily, but it depends on your definition of problems. If you have a naive or inexperienced developer working on the code, they could look at it and say "Hey, your code is not DRY, you suck." They could be wrong of course, but you still have to explain why to them, so that could be a problem.
Will keeping them together and using the same models for both MVC and Web API cause problems?
No, and let me give a reason why. Models for MVC and WebAPI are consumed by different frameworks. For example, in order to make sure a model property renders as a hidden input, you might decorate it with the [HiddenInput] attribute. There is no such concept in WebAPI models. Similarly, MVC has Display, Remote, and other attributes that you usually won't use on WebAPI models.
On the other side of the same coin, WebAPI models can use [DataContract] and [DataMember] attributes that don't have any meaning in MVC. You use these to give special names to your API output (for example, renaming XML or JSON nodes).
While you could have a single model double for use in both MVC and WebAPI, you could end up with those models having mixed concerns: for example, a [DataMember] attribute for API output formatting, and a [HiddenField] attribute for MVC form view rendering. One could view this as a manifestation of pollution.
As long as your model classes are simple data containers with no methods or intelligent behaviors, it's not a violation of DRY to have different model classes with the same properties / schemas. Why? Because it allows you to decorate these classes with different attributes that address different concerns.
Then again, if your models don't use any of these attributes, and you don't plan to, then it would be okay to have the same models double for both MVC and WebAPI. So the answer really is, it depends.
どちらも独自の目的があるので、一目でノーと言います。
mvcのviewmodelは、処理したデータのビューと検証を表すプロパティを対象としています。WebAPIはこの目的には使用されていないようです。したがって、ビューモデルとして機能できるエンティティがある場合でも、常にプロパティがあります。
また、変更に対するアプリケーションの管理が難しくなります。
ただし、アプリケーションがかなり小さい場合は使用できます。
それらを分離する場合、すべてを再コーディングまたはコピーアンドペーストする必要がある場合は、それらを分離しないでください。それらを分離することは何もコピーしないことを意味する場合、あなたは安全で賢明に分離することができます.
いつものように、このタイプの質問に対する答えは、「うーん、場合による」です。
個人的には、データ層、安静層、Web アプリケーションのすべてが参照する poco モデル専用のクラス ライブラリがあります。
これを行う前に私が見つけた唯一の落とし穴は、LinqToSql で生成されたクラス (したがって、おそらく EF も) が循環参照を持つことができるということでした。これは、ApiController クラスで JSON にシリアル化するときに WebApi がチョークし、無限ループに陥ります。