APIコントローラと基礎をなすサービス - 引数の検証の責任

Question

多分それは簡単な状況ですが、それは私にとっては混乱しており、正しい方法で対処する方法が必要です。

それは、単純なモデルはとして休耕であることを確認するには、次の

User * - * Project

（ユーザーが多くのプロジェクトに割り当てられ、プロジェクトがに割り当てられた多くのユーザーを持っています）。

私は特定のプロジェクトからユーザを割り当て、解雇のために、残りのコントローラを作成しました：

…\Api\v1\Projects\{projectId}\users\{userId} 

2つのHTTPアクションが許可されています。

• POSTプロジェクトに既存のユーザーを割り当てるアクションと
• がにDELETEユーザーをプロジェクトから退ける。 （それが正しい解決策であるかどうかはわかりませんが、それは私には役立ちます）。

APIコントローラは、これらの操作を実行するためにサービスレイヤーを使用します。サービスインターフェイスは次のとおりです。

void projectService.assignUser(int projectId, int userId) 
void projectService.dismissUser(int projectId, int userId) 

サービスは、これらの操作を実行するためにdbContextを使用します。

質問1：projectIdとuserIdが正しいかどうかをチェックする責任はどの要素にありますか？ IMHO再利用できるので、このロジックをサービスレイヤに配置する方がよいでしょう。

質問2：projectIdとuseridが正しくない場合（project/userが存在しない、または割り当てが許可されていないなど）、これらのメソッドは何を返すべきですか？

私の最初の考えはnull値を返すことでしたが、それはあまり意味がないと思います。主に、enitiyIdが正しくない場合、サービス内の同様のメソッドがnullを返すためです。例： projectService.getProject（projectId） - プロジェクトが存在しない場合はnullを返します。

2番目はboolを返すことでした。 Falseは少なくとも1つの引数が正しくない

3番目の考えは、メッセージとともにArgumentExceptionをスローすることでした。それは良いようですが、それは例外をキャッチするために、APIのコントローラになります。

Answer 1

Q1）私はそれらをサービスレイヤーに配置することは有効な考えだと思いますが、これらのメソッドを再利用したいと思う多くのシナリオを考えることができます。

Q2）これは少し難解で、意見の対象ですが、実際にビジネスロジックレイヤーと通信する方法（これらのメソッドはおそらく生きているでしょう）に依存します。私が最近使用したアプローチの1つは、サービスレイヤとビジネスレイヤ間で通信する特別なサービスメッセージクラスを作成することでした（プレゼンテーションレイヤとサービスレイヤの間でやりとりすることができます）。クラスは次のようになります。あなたの方法が成功した場合

public class BusinessLogicMessage<T> where T : new() 
    { 
     public BusinessLogicMessage(T result) 
     { 
      Result = result; 
      Status = BusinessLogicStatus.Success; 
      Message = string.Empty; 
     } 

     public BusinessLogicMessage(T result, BusinessLogicStatus status, string message) 
     { 
      Result = result; 
      Status = status; 
      Message = message; 
     } 

     public BusinessLogicStatus Status { get; set; } 
     public string Message { get; set; } 
     public T Result { get; set; } 
    } 

    public class BusinessLogicMessage 
    { 
     public BusinessLogicMessage() 
     { 
      Status = BusinessLogicStatus.Success; 
      Message = string.Empty; 
     } 

     public BusinessLogicMessage(BusinessLogicStatus status, string message) 
     { 
      Status = status; 
      Message = message; 
     } 

     public BusinessLogicStatus Status { get; set; } 
     public string Message { get; set; } 
    } 

    public enum BusinessLogicStatus 
    { 
     Success, 
     Failure, 
     Warning 
    } 

だから、あなたは単に成功のステータスを持つクラスのデフォルトコンストラクタを返します。失敗した場合やその他の場合は詳細を追加することができます。そのメソッドの特別な結果オブジェクトを返す必要がある場合は、に添付することができます。結果

私の2セントです。

より良い回答のために更新されました。

Answer 2

回答1：再利用のためにserviceId/userIdをサービス層に検証し、必要に応じてこれらの関数を呼び出す必要があります。

回答2： valid/invalid projectId/userIdに基づいてjsonを作成します。無効なIDの場合、両方が有効な場合のユーザーまたはプロジェクトに関する詳細が含まれ、エラーメッセージとエラーID（無効なプロジェクトの場合は1、無効なユーザーの場合は2）を返します。

A）JsonObject projectService.assignUser（INT PROJECTID、INT USERID）

例：
有効なID（両方）：

{ "STAT"： "OK"、 "はuserId"： "ここではuserId"、 "PROJECTID"： "ここPROJECTID"}

無効なプロジェクトID：

{ "errorMsg内容"： "無効なプロジェクトID"、 "STAT"： "失敗"、 "エラー"：1}

B）JsonObject projectService.dismissUser（INT PROJECTID、INT USERID）

有効IDS（両方）：

{ "STAT"： "OK"}

無効なユーザーID：

{ "errorMsg内容"： "無効なユーザーID"、 "STAT"： "失敗"、 "エラー"：2}