Message
私は非常に大きなコンストラクター(13個のパラメーター)を持つ複雑なエンティティ( )を持っていますが、これらのパラメーターのいくつかはエンティティ( Verb
)です。
別のエンティティのリポジトリが必要なものがいくつかあります(たとえば、いくつかのデフォルトの場合)。
IoCを使用し、コードをクリーン/ベストプラクティスに保つための良い方法は何ですか?
簡略化されたコード(デフォルトの動詞リストを静的コンストラクターによって個人的に構築された静的オブジェクトとして配置します。これは、メッセージエンティティが何らかのIRepositryを必要とする理由の最も単純な例です)。
private static IVerbRepository verbRepository;
static Message()
{
using (IKernel kernel = new StandardKernel())
{
verbRepository = kernel.Get<IVerbRepository>();
}
}
public Message(int id, string precis,
DateTime created, DateTime validTo,
PriorityType priority, Source source, SID createdBy,
string content = null, string helpText = null,
DateTime? validFrom = null, bool emailOnExpiry = false,
IEnumerable<SID> targetUsers = null,
IOrderedEnumerable<MessageVerb> verbs = null) : base(id)
{
Verbs = verbs ??
new List<MessageVerb>
{
new MessageVerb(
verbRepository.GetByName("Acknowledge"), true,
string.Empty)
}.OrderBy(x => x.IsDefault);
Precis = precis;
Created = created;
ValidTo = validTo;
Priority = priority;
Source = source;
CreatedBy = createdBy;
Content = content;
HelpText = helpText;
ValidFrom = validFrom;
EmailOnExpiry = emailOnExpiry;
TargetUsers = targetUsers;
}
一般的な方法は、コンストラクターにパラメーターを追加することのようです。これがどのように優れているのかわかりませんか?つまり、メッセージを作成するたびに、リポジトリを取得するためのコードを作成する必要があります。これをファクトリでラップアラウンドすると仮定すると、メッセージエンティティ用に異なるリポジトリを(実際にはそうでない場合でも)許可することは意味がありませんか?
編集1
最初のソリューションに基づいて、コードはこれを望みます、
public Message(IVerbRepository verbRepository ...) { }
同じドメインアセンブリの他の場所
public MessageService
{
private IVerbRepository VerbRepository {get; set;}
public static IOrderedEnumerable<MessageVerb> DefaultVerb {get;}
}
私のDDDの外のはるかに高いところ(メッセージの作成を受け入れる私のWebサービスとしましょう)
public class MessageWebService
{
private static IVerbRepository _verbRepository;
public void AddMessage(some parameters)
{
var message = new Message(_verbRepository, ...);
}
}