3
私のチームメイトと、Web APIコントローラがどのようなコードを保持すべきかについて議論しました。コントローラはビジネスロジックを保持してはならないが、ワークフローをどこに配置するか、ワークフローをビジネスロジックから完全に分離する必要があるかどうかは合意していません。Web Api - BLからワークフローを分離する
コントローラーコード：
public Response EndPoint(...)
{
var flow = new SomeFlow();
var response = flow.RunFlow(...);
return response;
}
フローコード：
public class SomeFlow
{
public HttpResponseMessage Activate(....)
{
var service = new Service();
var entities = someService.GetEntities();
if(entities == null) return new HttpResponseMessage(HttpStatusCode.NotFound);
foreach(var entity in entities)
{
BusinessLogicClass/Model.DoSomething(entity)
}
.....
.....
}
}
SomeFlow.csクラスが下に配置され
は、彼らは、エンドポイントは、このようになるはずだと思いますソリューションのビジネスロジックプロジェクト
私は彼らにこのstackoverflowの答えを示しました： https://stackoverflow.com/a/12694104/9062092 しかし、彼らはまだこのコードが読みやすいと言っています。
流れのクラスはビジネスロジックプロジェクトの下にあり、開発者はビジネスロジックをフロークラスの中に入れてBLをワークフローと結びつけることを奨励していると思います。パブリックメソッドが1つしかないこのクラスを作成する理由はなく、プロジェクト内で1回のみ使用されます。
両方の方法でテスト可能ですが、フロークラス内にある純粋なBLをテストするのが少し難しくなります。
ワークフローはビジネスロジックと見なされますか？
返信いただきありがとうございます！
提案された「フロー」オブジェクトは、依然として「HttpResponseMessage」のようなものを使用してアプリケーションタイプ（ウェブアプリケーション）に結合されます。 Webアプリケーションの一部であり、独自のものではありません。本当の疑問は...この論理はそれ自身の別個のものである必要があるのだろうか？それは他のWebアプリケーションでも使用されますか？他のタイプのアプリケーションでも使用されますか？それとも、動きの速い部分を欲しがるためだけに可動部分を追加するのですか？これはすべて非常に意見に基づいています。実際のところ失われたものは何ですか？ – David
'HttpResponseMessage'を返すものがビジネスロジックとしてどのように分類されるのか分かりません。このように 'SomeFlow'を作成しようとするならば、少なくともビジネスロジック層ではなく、Web APIプロジェクトに入れてください。 – Evk
ビジネスロジックをwebapiプロジェクトの下に置くべきではないことを理解するよりも、Single responsibilityの原則に違反する方が簡単だと思います。これらのクラスはWebAPIプロジェクトの内部に配置されても構いませんが、BLLプロジェクトの下に置かれることは望ましくありません。私は、フローを別のクラスに分けることによって得られるものは見当たりません。私たちは他のすべてのプロジェクトでそれらを2度以上使用したことはありません。 –