永続性の無視（PI）は、効率的な機能テストを実現するための重要なガイドラインです。一般的にインフラの目的に適用されるべきだと思います。しかし、このガイドラインはほとんどが従っていないと思われるWeb指向アーキテクチャ特にして、（WOA）RESTのAPI。RESTはデータ中心のアーキテクチャのように思われるため、体系的で費用のかかるエンドツーエンドのテストを防ぐために、PIがより一般的な方法でWOAに適用されない理由がわかりません。
RESTアーキテクチャへのPIの導入を容易にする可能性のあるアーキテクチャまたはプラクティスはありますか？あなたの経験に基づいて、RESTアーキテクチャでPIの原則に従おうとしましたか？そうでない場合、なぜですか？
それはすべてレイヤーと抽象化の問題です。データが内部でどこにどのように保持されているかを知るために、RESTエンドポイントは必要ありません。永続化メカニズムは、実行時に注入または交換できます。エンドポイントは、API呼び出しパラメーターを次のレイヤーが期待するものに変換するのに十分なだけ知っている必要があります（必要な場合）。確かに、多くのREST実装は永続性の知識をエンドポイントにロードしますが、それはRESTfulAPIに限定された問題ではありません。
SOLIDのDの少しを使用して、PIをRESTfulエンドポイントに導入できます。
WebAPIの例を使用すると、コントローラー（エンドポイント）は次のレイヤーのインターフェースについてのみ認識します。テストの目的で、そのレイヤーをモックして、テストをAPI自体に分離することができます。より複雑なロジックまたは複数のリポジトリへのアクセスが必要な場合は、次のレイヤーを永続レイヤーまたはサービスレイヤーにすることができます。
public class ValuesController : ApiController
{
//controller only knows about the interface to the next layer down
private readonly IServiceOrRepositoryLayer _serviceOrRepo;
//persistence or service layer injected into the constructor
//useful for testing
//could also inject a factory if more flexibility needed at runtime
public ValuesController(IServiceOrRepositoryLayer serviceOrRepo)
{
_serviceOrRepo = serviceOrRepo;
}
// GET api/values
public IEnumerable<SomePOCO> Get()
{
return _serviceOrRepo.ListAll();
}
// GET api/values/5
public SomePOCO Get(int id)
{
return _serviceOrRepo.Get(id);
}
// POST api/values
public void Post(SomePOCO value)
{
//can either pass the value directly or transform it here
//to what the next layer needs
_serviceOrRepo.Create(value);
}
// PUT api/values/5
public void Put(int id, SomePOCO value)
{
_serviceOrRepo.Update(value, id);
}
// DELETE api/values/5
public void Delete(int id)
{
_serviceOrRepo.Delete(id);
}
}
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加