回答編集履歴
1
追記
test
CHANGED
|
@@ -44,11 +44,11 @@
|
|
|
44
44
|
|
|
45
45
|
|
|
46
46
|
|
|
47
|
-
Interactor が Repository の実体に依存しているのでこれ等ソースコードの実装はクリーンアーキテクチャではなくレイヤードアーキテクチャに近いと思います。
|
|
47
|
+
1.Interactor が Repository の実体に依存しているのでこれ等ソースコードの実装はクリーンアーキテクチャではなくレイヤードアーキテクチャに近いと思います。
|
|
48
48
|
|
|
49
49
|
|
|
50
50
|
|
|
51
|
-
Entity 自体の振る舞いが Dispose メソッド1つしかないのでドメイン貧血症になっています。データベースや WebAPI など外の都合に影響されないなら DomainService をわざわざ作らずに下記のようにするのが十分な気もしますが、いかがでしょう。
|
|
51
|
+
2.Entity 自体の振る舞いが Dispose メソッド1つしかないのでドメイン貧血症になっています。データベースや WebAPI など外の都合に影響されないなら DomainService をわざわざ作らずに下記のようにするのが十分な気もしますが、いかがでしょう。
|
|
52
52
|
|
|
53
53
|
|
|
54
54
|
|
|
@@ -120,7 +120,7 @@
|
|
|
120
120
|
|
|
121
121
|
|
|
122
122
|
|
|
123
|
-
Entity が Dispose を持っているのも何だか Entity 以上のことをしているように思います。もし Image のようなリソースを持っているのであれば Entity の外（アプリケーションやフレームワーク、リポジトリなど）で生成したリソースをDIで受け取るのが適切だと思います。リソースを破棄するときも Entity の外 (生成したとき同じクラス)で行います。
|
|
123
|
+
3.Entity が Dispose を持っているのも何だか Entity 以上のことをしているように思います。もし Image のようなリソースを持っているのであれば Entity の外（アプリケーションやフレームワーク、リポジトリなど）で生成したリソースをDIで受け取るのが適切だと思います。リソースを破棄するときも Entity の外 (生成したとき同じクラス)で行います。
|
|
124
124
|
|
|
125
125
|
|
|
126
126
|
|
|
@@ -178,4 +178,8 @@
|
|
|
178
178
|
|
|
179
179
|
|
|
180
180
|
|
|
181
|
+
4.Presenter クラスがありませんが、DataUpdated は Interactor ではなくそちらで持つのが適切と思います。
|
|
182
|
+
|
|
183
|
+
|
|
184
|
+
|
|
181
|
-
|
|
185
|
+
5.規模が大きくなかったり、単体テストなどを考えていないなら今のようにインターフェースが存在しない実装で不満はないのかもしれませんが、各々のクラスが密結合になっているのでインターフェース等を使って疎結合にした方が機能変更には強くなります。
|