任意のモデルをサポートする汎用Web APIコントローラ

Question

プロジェクト内のどのモデルもサポートする汎用Web APIを使用できますか？

class BaseApiController<T> :ApiController 
{ 
    private IRepository<T> _repository; 

    // inject repository 

    public virtual IEnumerable<T> GetAll() 
    { 
     return _repository.GetAll(); 
    } 

    public virtual T Get(int id) 
    { 
     return _repositry.Get(id); 
    } 

    public virtual void Post(T item) 
    { 
     _repository.Save(item); 
    } 
    // etc... 
} 

class FooApiController : BaseApiController<Foo> 
{ 
    //.. 

} 

class BarApiController : BaseApiController<Bar> 
{ 
    //.. 
} 

これは良いアプローチでしょうか？

すべての後、私はちょうどCRUDメソッドを繰り返しmは？この基本クラスを使って私の仕事をすることはできますか？

これはOKですか？あなたはこれをしますか？どんな良いアイデアですか？

Answer 1

私が何かアップし、クライアントにデモするために実行されている取得するための小規模なプロジェクトのためにこれをやりました。ビジネスルール、検証、その他の考慮事項の詳細がわかり次第、私は基本クラスからCRUDメソッドをオーバーライドしなくて済むようになり、長期的な実装としては機能しませんでした。

すべてが同じタイプのIDを使用していない（私は既存システムで働いていた）ので、私は、ルーティングの問題に走りました。いくつかのテーブルはintプライマリキーを持ち、一部はstrings、その他はguidsでした。

私はそれにも問題がありました。結局、私が最初にやったときに滑らかに見えましたが、実際に実際の実装でそれを使用することは、別の問題であることが判明しました。

Answer 2

間違いなく可能です。私は前にそれを行う理由は一度もありませんでしたが、それがあなたの状況に合っていれば、それは良いことです。

あなたのモデルのすべてが保存され、まったく同じ方法で検索することができた場合は、おそらく彼らはただ、すべてかかわらず、代わりに同じコントローラにすべきですか？

Answer 3

前の回答で述べたように、それは絶対に可能です。これは良いアプローチであり、確かに良いアーキテクチャです。しかし、私はあなたのコントローラーがなぜ公開されていないのかを知りません。あなたの問題であるかもしれないし、あなたのコードがうまくいきませんでしたか？

Answer 4

あなたのリポジトリ内のすべての力仕事を扱う限り、これでは何も問題。ベースステートの例外をラップする/処理する必要があるかもしれません。他の車や他の何を追跡することがあり、一方のユーザーが、ユーザーとアカウントを持ってしたいことがあります。つまり - 私は実際にユーザーが独自のエンティティとのAPIを定義することができます大規模なプロジェクトのために似た何かをやっている

。それらはすべて同じ内部コントローラーを使用しますが、それぞれに独自のエンドポイントがあります。

ジェネリックを使用していないため、私たちのコードがどれほど有用かわかりません（各オブジェクトはメタデータとして管理され、JObject辞書として操作/渡されます）。私たちはやって、多分思考のための食糧を提供しています

[POST("{primaryEntity}", RouteName = "PostPrimary")] 
public async Task<HttpResponseMessage> CreatePrimary(string primaryEntity, JObject entity) 
{ 
    // first find out which params are necessary to accept the request based on the entity's mapped metadata type 
    OperationalParams paramsForRequest = GetOperationalParams(primaryEntity, DatasetOperationalEntityIntentIntentType.POST); 

    // map the passed values to the expected params and the intent that is in use 
    IDictionary<string, object> objValues = MapAndValidateProperties(paramsForRequest.EntityModel, paramsForRequest.IntentModel, entity); 

    // get the results back from the service and return the data to the client. 
    QueryResults results = await paramsForRequest.ClientService.CreatePrimaryEntity(paramsForRequest.EntityModel, objValues, entity, paramsForRequest.IntentModel); 
     return HttpResponseMessageFromQueryResults(primaryEntity, results); 

} 

Answer 5

EFモデルやコードファーストから生成された1が、これはあなたのシステムのためにあまりにも複雑であるようにあなたは、事前に定義されたデザイン時のクラスを持っている場合。これは、データ・エンティティ・クラスが実行時に生成される私のプロジェクトのような、あらかじめ定義されたクラスを持っていないとすばらしいことです。

私の解決策（まだ正しく実装されていない）は、すべての要求に対して汎用コントローラを選択するカスタムIHttpControllerSelectorを作成することでしたが、コントローラの記述子タイプを、

また良い出発点は、他の人が言ったように何をやってすることは間違いなく可能ですhttp://entityrepository.codeplex.com/（私はここstackoverflowの上でこのどこかを見つけた）

Answer 6

です。しかし、リポジトリーの依存関係については、依存関係注入を使用する必要があります。私の典型的なコントローラ（ApiまたはMVC）は次のようになります。

public class PatientCategoryApiController : ApiController 
{ 

    private IEntityRepository<PatientCategory, short> m_Repository; 
    public PatientCategoryApiController(IEntityRepository<PatientCategory, short> repository) 
    { 
     if (repository == null) 
      throw new ArgumentNullException("entitiesContext is null"); 

     m_Repository = repository; 
    } 
} 

これは典型的なコンストラクタ注入パターンです。 NInjectやAutofacのようなDIやコンテナのことをよく理解している必要があります。あなたがDIを知っていないなら、あなたは長い道を先にしています。しかしこれは優れたアプローチです。この本を見てください。 https://www.manning.com/books/dependency-injection-in-dot-net