前回はRepositoryを作成しました。ただ戻り値のEntityを実装していないため,コンパイルエラーのままです。今回はそのEntityを作っていきたいと思います。
Entitiesフォルダーの作成
ドメインプロジェクトを右クリックし,「追加」「新しいフォルダー」を選択し,新規フォルダーを作成し,フォルダー名を「Entities」に変更しましょう。
MeasureEntityの作成
作成したEntitiesフォルダーの中にクラスを追加し,名前を「MeasureEntity」にします。
MeasureEntityの実装
作成したMeasureEntityに対して,次のように実装します。
using System; namespace NDDD.Domain.Entities { public sealed class MeasureEntity { public MeasureEntity( int areaId, DateTime measureDate, float measureValue) { AreaId = areaId; MeasureDate = measureDate; MeasureValue = measureValue; } public int AreaId { get; } public DateTime MeasureDate { get; } public float MeasureValue { get; } } }
アクセス修飾子
「public sealed class MeasureEntity」
まずアクセス修飾子はpublicです。これはWinFormやInfrastructure層からも参照するためです。そしてsealedキーワードを書いています。Entityは基本的に継承させません。Entityを継承すると,常にサブクラスとスーパークラスを確認しながら実装や解析をしないといけないので,非常に複雑なコードになります。これはEntityに限らず,継承は必要に迫られるまで,極力しないほうがいいので,クラスは基本的にsealedで作成します。どうしても継承が必要になったらsealedを外しましょう。
コンストラクタは完全コンストラクタパターンで
public MeasureEntity( int areaId, DateTime measureDate, float measureValue) { AreaId = areaId; MeasureDate = measureDate; MeasureValue = measureValue; }
続いてコンストラクタを書いています。プロパティのすべてが指定されるように,すべての値を指定させています。これを完全コンストラクタパターンといいます。クラスがNewされて,インスタンスが生成された時点で,すべての値が設定されていることを保証するクラスです。Entityは基本的にインスタンス生成時にすべての値が決まっていることが多いので,できるだけこのようにし,プロパティはすべて読み取り専用{ get; }としておきます。どうしても後から変更が必要な項目のみを{ get; set;}としましょう。そのほうが,値の変更箇所が限定的になるので,後で解析する人が,コードを読みやすくなります。
プロパティ
public int AreaId { get; } public DateTime MeasureDate { get; } public float MeasureValue { get; }
そして,プロパティを3つ記述しています。
前述した通り,すべて「get」のみの読み取り専用です。この場合はコンストラクタでのみ設定が可能なので,完全コンストラクタパターンとなります。
アクセス修飾子はpublicで,型は,それぞれ,データベースなど取得先の型に合わせます。今回はAreaIdをint,MeasureDateを日付型,MeasureValueをfloat型としています。
リポジトリーのusing追加
これでEntityが完成したので,IMeasureRepositoryのコンパイルエラーを取り除きます。波線の出ているMeasureEntityの上で「ctrl+ドット」+Enterキーを押すか,クラスの上部に「using NDDD.Domain.Entities;」を追加しましょう。これでコンパイルエラーが取り除かれるはずです。
using NDDD.Domain.Entities; namespace NDDD.Domain.Ripositories { public interface IMeasureRepository { MeasureEntity GetLatest(); } }
#02_プロジェクトの追加
#03_依存関係
#04_ドメイン駆動開発でApplication層は必要?
#05_Domainのフォルダー構成
#06_Infrastructureのフォルダー構成
#07_WinFormのフォルダー構成
#08_Testsのフォルダー構成
#09_テスト駆動で実装するための事前準備
#10_テストコードとViewModelの追加
#11_テストコードを追加する
#12_ Repositoriesフォルダーの作成
#13_ Entitiesフォルダーの作成
#14_ Mockの作成
#15_フォーム画面の作成
#16_画面のコントロールデータバインドする
#17_Fakeを使ってタミーデータを画面に表示させる
#18_Fakeデータを画面に通知する
#19_PropertyChangedの方法を変更する
#20_Fakeとデータベースの値を切り替える方法
#21_Sharedクラスを作成する
#22_クラスを生成するファクトリークラスを作る
#23_#if DEBUGでFakeデータがリリースされないようにする
#24_DEBUGモードであることをわかりやすくしておく
#25_Factories以外から生成できないようにしておく
#26_Factoriesの呼び出しはViewModelで行う
#27_外部の設定ファイルの値で判断する
#28_Fakeデータを切り替える方法
#29_FakePathを設定ファイルとSharedに移す
#30_Fakeデータのバリエーション
#31_Shareクラスの活用方法
#32_ベースフォームを作る
#33_SharedにログインIDを記憶する
#34_BaseFormでログインユーザーを表示する
#35_ValueObject
#36_ValueObjectを作成する
#37_抽象クラスValueObjectを使用してイコールの問題の解消
#38_AreaIdにビジネスロジックを入れる
#39_AreaIdクラスをEntityに乗せる
#40_MeasureDateの作成
#41_MeasureValueの作成
#42_オブジェクト指向の自動化
#43_Repositoryの具象クラス
#44_例外処理
#45_例外の作成
#46_インナーエクセプション
#47_例外の欠点
#48_メッセージの区分
#49_エラー処理の共通化
#50_ログの出力
#51_タイマー処理はどこに置く?
#52_タイマークラスの作成
#53_StaticValues
#54_Logics
#55_Helpers
#56_Module
#57_トランザクションはどこでかける?
#58_特徴を見極める
#59_さいごに