私はリポジトリパターンを使用していますが、どのデータ型を返すべきか不思議でした。私のデータベースでは、固定長に基づいて分割する必要がある可変長の文字列があります。私は最初に文字列を渡し、サービス層に構成された列の長さに基づいた解析をさせることを考えていました。私は本当にリポジトリ層から文字列を渡す考え方がなく、むしろ完全なオブジェクトを渡すだろう。文字列を渡すことは、責任の分離が十分ではないように思えますが、リポジトリを別のメソッドに移動させて文字列を解析する必要があり、解析を行うことはリポジトリにとってあまりにも多くの作業のようです。この場合、レポやサービスの責任はどのようなものであるべきかの提案はありますか？リポジトリのパターンとデータ型が返される
リポジトリは、メモリオブジェクトのコレクションとして機能するはずなので、アプリケーションが処理しようとしているオブジェクトの種類にかかわらず、インスタンスを返す必要があります。アプリケーションが解析されたオブジェクトを期待している場合は、それを返す必要があります。
解析のためにサービスを利用することは、いずれにせよインフラストラクチャの一部です。ほとんどのリポジトリの実装では、永続化されたデータを返す前に何かをしなければならないので、これは良いことです。
たとえば、リポジトリがドメインレイヤオブジェクトを返していても、その永続性がL2Sを使用している場合は、L2Sデータをドメインオブジェクトにマップすることができます。これを行うには、リポジトリ外のものに依存する必要があります。それをサービスなどと呼んでください。おそらく、マッピングを使ってリポジトリコードをクルーグしたくないでしょう。
パースメソッドは、リポジトリクラス内のプライベートメソッドであるため、実際のパースを実際のreposメソッドから隠すことができます。あるいは、Utilクラスに存在する拡張メソッドでもかまいません。
私はあなたがSRPに違反しているように見えるので、あなたはsvc層にその文字列の解析を入れないのは正しいと思います。
リポジトリは確実にビジネスオブジェクトを返す必要があります。
誰が解析を行うべきかについては、いくつかのことを行うことができます。おそらく、ヘルパー関数などを使って、文字列を正しい形式に解析することができます。リポジトリ外では役に立たない場合は、コードをリファクタリングして読みやすくすることができます。
リポジトリクラスをサービスレイヤーに渡すべきではないと主張するのは正しいです。したがって、リポジトリをクリーンアップするためのリファクタリングの方法は、そのレイヤーで行う必要があります。
ええ、私はサービス層と話すことを考えていませんでしたが、サービスを解析するだけですが、リポジトリに構文解析（または渡されたインターフェイス）を行い、モデルオブジェクトを返します。ありがとう+1 – CSharpAtl
私の好みの選択肢は、最初に固定幅の区切り文字列にデータを格納しないことです。 :)
私はそれについて考えている：これは、データの実際のストレージについて最も気にしているのは誰ですか？文字列形式がビジネスロジックの必須部分ではないレガシーシステムのアーティファクトである場合（つまり、ストレージメカニズムを変更する場合は文字列を取り除くことになります）、リポジトリの背後に隠します。それがデータの不可欠な部分だがビジネスロジックから抽象化している場合は、それをサービスに入れてください。
リポジトリに残しておくと、その文字列を操作するための特別なクラスを作成し、それをリポジトリに（インターフェイスとして）渡すことができます。そうすれば、Crazyのような文字列処理コードを単体テストできます（必要に応じて別の場所に再利用できます）。
リポジトリがデータを解析する方法のデータを取得する別のオブジェクトを呼び出す必要がある場合でもですか？私はそのように傾いています...データストレージが後で変更された場合、サービスだけでなくレポにも対処する必要があります。 – CSharpAtl
あなたの場合は、ジョセフが示したように、拡張メソッドなどの単純なものかもしれません。しかし、はい、リポジトリに永続性の問題のみを処理させ、解析ルールを他のオブジェクトに残すほうがおそらく最適です。 – jlembke