c# - 返されるリポジトリ パターンとデータ型

Question

私はリポジトリ パターンを使用しており、どのデータ型を返すべきか疑問に思っていました。私のデータベースには、固定長に基づいて分割する必要がある可変長の文字列があります。最初は、文字列を渡して、構成された列の長さに基づいてサービス レイヤーに解析を行わせることを考えていました。リポジトリ層から文字列を渡すという考えはあまり好きではなく、むしろ完全なオブジェクトを渡したいと思っています。文字列を渡すことは責任の分離が不十分であるように思えますが、リポジトリが文字列を解析する方法を取得するために別のメソッドに移動する必要があり、解析を実行することはリポジトリにとって負担が大きすぎるように思えます。この場合、レポとサービスの責任は何ですか?

Answer 1

リポジトリは必ずビジネス オブジェクトを返す必要があります。

誰が解析を行うべきかについては、多くのことを行うことができます。おそらく、ヘルパー関数などを使用して、文字列を正しい形式に解析できます。リポジトリの外で役に立たない場合は、コードをリファクタリングして読みやすくすることができます。

リポジトリ クラスがサービス層に到達するべきではないと主張するのは正しいので、リポジトリをクリーンアップするためにリファクタリングする方法は何であれ、それ以上ではなく、その層で実行する必要があります。

Answer 2

リポジトリはメモリ内オブジェクトのコレクションとして機能することになっているため、アプリケーションが処理することを期待しているオブジェクトのタイプのインスタンスを返す必要があります。アプリケーションが解析されたオブジェクトを期待している場合は、それを返す必要があります。

とにかく、解析を行うために何らかのサービスに依存することは、すべてインフラストラクチャの一部です。ほとんどのリポジトリ実装では、永続化されたデータを返す前に何らかの処理を行う必要があるため、これは良いことです。

たとえば、リポジトリがドメイン レイヤー オブジェクトを返しているが、永続性が L2S を使用している場合、L2S データをドメイン オブジェクトにマップすることができます。これを行うには、リポジトリの外部に依存する必要があります。それをサービスなどと呼んでください。おそらく、マッピングでリポジトリコードをクルージしたくないでしょう。

Answer 3

解析メソッドは、リポジトリ クラス内のプライベート メソッドである可能性があるため、実際の解析をパブリックの実際のリポジトリ メソッドから隠します。あるいは、Util クラスに存在する拡張メソッドである可能性もあります。

SRPに違反しているように見えるため、その文字列の解析をsvcレイヤーに配置しないというあなたの考えは正しいと思います。

Answer 4

私の好みの選択は、そもそもデータを固定幅で区切られた文字列に格納しないことです。:)

私はこれについて次のように考えています: データの実際のストレージを最も気にするのは誰ですか? 文字列形式が一部のレガシー システムのアーティファクトであり、ビジネス ロジックの重要な部分ではない場合 (つまり、ストレージ メカニズムを変更すると文字列が削除される場合)、それをリポジトリの背後に隠します。それがデータの重要な部分であるが、ビジネス ロジックから抽象化している場合は、それをサービスに入れます。

リポジトリに残しておく場合は、その文字列を操作するための特別なクラスを作成し、(インターフェイスとして) リポジトリに渡すことができます。そうすれば、文字列処理コードを狂ったように単体テストして (必要に応じて別の場所で再利用して)、リポジトリをシンプルなままにすることができます。