回答編集履歴
1
null 許容参照型に関するリンクを追加。
answer
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
バリデーションの責務というと最近こんな記事を見かけました
|
|
2
2
|
|
|
3
|
-
[Clean Architectureにおいてバリデーションはどこでやるべきか](https://ikenox.info/blog/validation-in-clean-arch/)
|
|
3
|
+
* [Clean Architectureにおいてバリデーションはどこでやるべきか](https://ikenox.info/blog/validation-in-clean-arch/)
|
|
4
4
|
|
|
5
5
|
結論としては「レイヤーごとの責務においてやるべき」というややふわっとした回答になります。
|
|
6
6
|
|
|
@@ -8,6 +8,8 @@
|
|
|
8
8
|
|
|
9
9
|
C# 8.0 以降であれば「null 許容参照型」を有効にすることで、参照型であっても「null/非null」を明示的にコードで示さなければならなくなるので、nullチェックの責務を負った地点以降のコードはnullチェックが不要になります。
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
* [null 許容参照型 - Microsoft Doc](https://docs.microsoft.com/ja-jp/dotnet/csharp/nullable-references)
|
|
12
12
|
|
|
13
|
+
つまり、メソッドが非null参照型で受け取ったなら、それはnullチェック済みであることが自明となっているということであり、「null 許容参照型」を有効にすることはnullチェックの責務を負う場所の明確化を型システムレベルで求めることが出来るようになると言えます。
|
|
14
|
+
|
|
13
15
|
「null 許容参照型」を活用する前提で、改めてnullチェックの責務はどこで追うべきかを考えると、例えば入力を受け取る場所（UIとDomainを繋ぐプレゼンター層、またはDatabaseからデータ取得するリポジトリ層など）においてチェックし、いわゆるモデル層、ビジネスロジック部分で受け取る時は常に非nullで受け取る（ただし内部的なプロパティがオプション扱いである場合にnull許容として明示的にマークする）といったことが考えられると思います。
|