回答編集履歴
1
追記
answer
CHANGED
|
@@ -21,9 +21,9 @@
|
|
|
21
21
|
|
|
22
22
|
### 他に気になる点
|
|
23
23
|
|
|
24
|
-
Interactor が Repository の実体に依存しているのでこれ等ソースコードの実装はクリーンアーキテクチャではなくレイヤードアーキテクチャに近いと思います。
|
|
24
|
+
1.Interactor が Repository の実体に依存しているのでこれ等ソースコードの実装はクリーンアーキテクチャではなくレイヤードアーキテクチャに近いと思います。
|
|
25
25
|
|
|
26
|
-
Entity 自体の振る舞いが Dispose メソッド1つしかないのでドメイン貧血症になっています。データベースや WebAPI など外の都合に影響されないなら DomainService をわざわざ作らずに下記のようにするのが十分な気もしますが、いかがでしょう。
|
|
26
|
+
2.Entity 自体の振る舞いが Dispose メソッド1つしかないのでドメイン貧血症になっています。データベースや WebAPI など外の都合に影響されないなら DomainService をわざわざ作らずに下記のようにするのが十分な気もしますが、いかがでしょう。
|
|
27
27
|
|
|
28
28
|
```C#
|
|
29
29
|
// 消す
|
|
@@ -59,7 +59,7 @@
|
|
|
59
59
|
}
|
|
60
60
|
```
|
|
61
61
|
|
|
62
|
-
Entity が Dispose を持っているのも何だか Entity 以上のことをしているように思います。もし Image のようなリソースを持っているのであれば Entity の外（アプリケーションやフレームワーク、リポジトリなど）で生成したリソースをDIで受け取るのが適切だと思います。リソースを破棄するときも Entity の外 (生成したとき同じクラス)で行います。
|
|
62
|
+
3.Entity が Dispose を持っているのも何だか Entity 以上のことをしているように思います。もし Image のようなリソースを持っているのであれば Entity の外（アプリケーションやフレームワーク、リポジトリなど）で生成したリソースをDIで受け取るのが適切だと思います。リソースを破棄するときも Entity の外 (生成したとき同じクラス)で行います。
|
|
63
63
|
|
|
64
64
|
```C#
|
|
65
65
|
internal class Entity
|
|
@@ -88,4 +88,6 @@
|
|
|
88
88
|
}
|
|
89
89
|
```
|
|
90
90
|
|
|
91
|
+
4.Presenter クラスがありませんが、DataUpdated は Interactor ではなくそちらで持つのが適切と思います。
|
|
92
|
+
|
|
91
|
-
|
|
93
|
+
5.規模が大きくなかったり、単体テストなどを考えていないなら今のようにインターフェースが存在しない実装で不満はないのかもしれませんが、各々のクラスが密結合になっているのでインターフェース等を使って疎結合にした方が機能変更には強くなります。
|