0

現在、Repository/UnitOfWorkパターンがダウンしています。しかし、どうすれば取り除くことができるのか理解できないハードカップリングが1つあります。

これは私のパターンの概要です：

ビジネスロジック層

  • IRepository
    • タイプ制約として使用
  • IRepository <TModel、TDTO>
    • IRepositoryを実装します
    • 一般的なCRUDメソッド
  • IEmployeeRepository <TModel>
    • IRepository <TModel、EmployeeDTO>を実装します
    • 一部の従業員固有の方法
  • IUnitOfWork
    • リポジトリのゲッター
    • 保存方法
  • IEntityWithId
    • DTOとEFPOCOにIDと呼ばれるInt32フィールドを強制（および公開）するためのインターフェイス
    • タイプ制約として使用
  • EmployeeDTO（実装されたEmployeeRepositoryでAutoMapperとマッピングされます）
    • コアプロジェクトおよび（今後の）テストプロジェクトで使用されるDTOエンティティ

データレイヤー（Ninjectで注入）

  • UnitOfWork
    • EntityFrameworkに基づくIUnitOfWorkの実装
  • EmployeesRepository
    • IEmployeeRepositoryの実装<TModel>
  • 従業員
    • EF POCO

芯

  • EmployeesController
    • パラメーター化されたコンストラクターEmployeesController（IUnitOfWork unitOfWork）
    • IUnitOfWorkは、（データレイヤーからの）UnitOfWorkとしてNinjectモジュールで注入されます

これらは、私の汎用IRepositoryインターフェースの問題メソッドです。

TDTO Find(Expression<Func<TModel, bool>> filter);

と

IEnumerable<TDTO> FindAll(Expression<Func<TModel, bool>> filter);

ご覧のとおり、そこにはTModelがあり、結果をフィルタリングするための式を作成するために使用されます。DTOで式を使用するようなこともできますが、DTOにマップされた従業員の完全なリストが必要になります（SQLフィルターは生成されませんが、SELECT * FROM Employee結果リストはフィルター処理されます）。したがって、これは適切なオプションではありません。

もう1つの、より実行可能であるが最適ではないソリューションは、動的LINQを使用することです。そうすれば、Find / FindAllメソッドで単純な文字列を渡して、TModel要件を取り除くことができます。ただし、これは、コードがマジックストリングで埋められるため、リファクタリングが煩わしいことを意味します。

4

2 に答える 2

1

これを投稿したのと同じように、自分の問題がどこにあるのかがわかったと思います。

Find（）とFindAll（）は存在するべきではありません。IEmployeeRepositoryにFindEmployeeByName（string name）のようなより具体的なメソッドを記述し、次のように実装する必要があります。

EmployeeDTO FindEmployeeByName(string name)
{
    return Mapper.Map<EmployeeDTO>(dbSet.Where(o=>o.name.Contains(name)).FirstOfDefault());
}

誰かがこれがそれを行うための適切な方法であることを確認できますか？または、さらに良いものを提案しますか？

編集

また、Find（Expression ...）メソッドとFindAll（Expression ...）メソッドを保持したい場合は可能ですが、これらはデータレイヤーにあり、コードの繰り返しを避けるために実装されたメソッドによって使用されます。ただし、ビジネスロジック以外の基礎となるデータ構造の知識が必要なため、コントローラーで使用しないでください。とは言うものの、それらはBaseRepository <TModel>（私はすでに持っていますが、物事をより単純にするために言及していません）に実装し、EmployeesRepositoryをBaseRepositoryの拡張にすることができます。このように、すべてのリポジトリには、モデル対応のジェネリックのようなメソッドがすでにあります。

私がそれをきちんと説明したかどうかはわかりません。不明な点がある場合はお知らせください。これを編集して改善するよう努めます。

于 2012-10-29T17:11:21.683 に答える
0

これを行う別の方法は、データレイヤーをビジネスレイヤーに依存させ、リポジトリの「プロジェクト」エンティティをビジネスオブジェクト（DTO）に含めることです。このように、BLは下部にあり、UIとデータはBLに依存しますが、UIとデータは相互に依存しません。

これは、依存性注入に関する彼の本でMarkSeemannによって支持された方法です。

于 2012-10-29T17:16:28.030 に答える