0
私は、Clean ArchitectureとDomain Driven DesignについてのPluralsightに関するいくつかのコースに従っていました。 DDDに関するEric Evanの本が届くのを待っているうちに、次のような状況と質問があります。DDDアーキテクチャを使用する場合、アプリケーション層でJsonProperty属性を使用できますか？
私は新しいプロジェクトを設定しています。
- MyProject.Application
- MyProject.Common
- MyProject.Domain
- MyProject.Infrastructure
- MyProject.Persistance
- MyProject.WebApi
WebApiでモデルを返すことがビジネス上の要件です。
- 私の命名規則に一致しません。
- は醜いです。
このモデルは、MyProject.Applicationプロジェクト内に存在します。たとえば、次のように
namespace MyProject.Application
{
public class MyModel
{
public string _communityname { set; get; }
public List<string> photolist { set; get; }
public string postedby { set; get; }
}
}
通常、私は素敵な、それを維持するためにモデルのこれらの種類にJsonProperyのattibuteを適用する：
namespace MyProject.Application
{
public class MyModel
{
[JsonProperty("_communityname")]
public string CommunityName { set; get; }
[JsonProperty("photolist")]
public List<string> PhotoUrls { set; get; }
[JsonProperty("postedby")]
public string PostedBy { set; get; }
}
}
しかし、私はそれについて考えて...と私に言います：アプリケーション層は、 '物事'がどのように提示されるかについて心配すべきではありません。これは、プレゼンテーションレイヤのタスクです（この場合はWebApiです）。
これは間違いありませんか？アプリケーション層が通常のモデルを返し、WebApiにこれをビジネスに必要な任意の（醜い）プレゼンテーション形式にキャスト/変換させる必要があります。
事前に感謝します。
これは適切な方法だとは言えませんが、私はWebApiのための単発モデルを用意しておきたいと思います。その方法で、私が望むすべての属性でカバーすることができます私のアプリケーションのモデルには影響しません。 – TyCobb
はい。私もこのオプションを検討しています。それはちょうど1つで、おそらくこの調整を必要とする2つのエンドポイントです。私はFranのanwerを見ていて、計画が出てくる – JonHendrix
@Tweek WebApi/MVCプロジェクトでは、内部ドメインロジックとUI/RESTのロジックが切り離されているので、常に別のビューモデルを使用します。私はそれがクリーナーだと思う。 http://stackoverflow.com/questions/4878937/why-should-i-use-view-models – Fran