0

ASP.NET MVC (C#) を使用してサイトを開発するとき、アーキテクチャとしてドメイン駆動設計 (N 層) を使用しました。

(データベース テーブルを使用せずに) アプリの設定/構成を作成する方法を知りたいです。

最初に .settings ファイルについて考えましたが、これが正しいアプローチであるかどうかはまだわかりません (たとえば、どこに保存する必要がありますか?)。そのため、web.config に構成値を追加し、DDD 設計を壊さないように、web.config から AppConfigurationManager を生成する t4 テンプレートをコア レイヤーに作成しました。

それでも、私は悪いアプローチをしていると思います。

では、ドメイン駆動設計を扱う場合、どのように構成を保存することをお勧めしますか?

私の t4 テンプレート (アイデアを得るのに役立つ場合):

<#@ template debug="false" hostspecific="true" language="C#" #>
<#@ output extension=".cs" #>
<#@ assembly Name="System.Configuration" #>
<#@ assembly name="System.Xml" #>
<#@ assembly name="System.Linq" #>
<#@ assembly name="System.Collections" #>
<#@ assembly name="System.Xml.Linq" #>
<#@ assembly name="System.Net" #>
<#@ assembly name="System" #>
<#@ import namespace="System.Configuration" #>
<#@ import namespace="System.Xml" #>
<#@ import namespace="System.Net" #>
<#@ import namespace="Microsoft.VisualStudio.TextTemplating" #>
<#@ import namespace="System.Xml.Linq" #>
<#@ import namespace="System.Linq" #>
<#@ import namespace="System.Collections" #>
<#@ import namespace="System.Collections.Generic" #>
// ------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//  
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
// ------------------------------------------------------------------------------
using System;
using System.Configuration;

namespace KNadlan.Core.Configuration
{
    public partial class AppConfigurationManager
    {
        <#
        string path = @"C:\Visual Studio 2012\Projects\MyApp\MyApp.Web.UI\Web.config";
        string configNamespace = "myapp";

        var xDocument = XDocument.Load(path);
        var results =   xDocument.Descendants("appSettings");

        foreach (var xElement in results.Descendants())
        {
            string origKeyName = xElement.Attribute("key").Value.Trim();
            string keyName = origKeyName;

            /* Skip on third-party configurations */
            if (!string.IsNullOrEmpty(configNamespace))
            {
                if (!keyName.StartsWith(string.Format("{0}:", configNamespace)))
                {
                    continue;
                }

                keyName = keyName.Substring(string.Format("{0}:", configNamespace).Length);
            }

            /* Valid key? */
            if (!System.Text.RegularExpressions.Regex.IsMatch(keyName, @"^([a-zA-Z0-9]+)$", System.Text.RegularExpressions.RegexOptions.Compiled | System.Text.RegularExpressions.RegexOptions.IgnoreCase))
            {
                continue;
            }

            /* Format field and property names */
            string fieldName = "_" + keyName.Substring(0, 1).ToLower() + keyName.Substring(1);
            string propertyName = keyName.Substring(0, 1).ToUpper() + keyName.Substring(1);
            #>

        #region <#= propertyName #>

        private static string <#= fieldName #> = ConfigurationManager.AppSettings["<#= origKeyName #>"];
        public static string <#= propertyName #>
        {
            get { return <#= fieldName #>; }
            set
            {
                <#= fieldName #> = value;
                ConfigurationManager.AppSettings["<#= origKeyName #>"] = value;
            }
        }

        #endregion
        <#
        }
        #>
    }
}
4

1 に答える 1

2

ドメイン レイヤーから構成にアクセスすることは、ドメイン サービスに適している場合がありますが、サービスを単独でテストするのが少し難しくなる可能性があります。

ところで、エンティティと値オブジェクトからのそのようなアクセスは避けるべきです。

より良い方法は、インフラストラクチャ レイヤーで構成を読み取り、ドメイン オブジェクトのコンストラクターの引数を介して必要な値を挿入することです。ファクトリとリポジトリはインフラストラクチャの一部であるため、必要に応じてそのような構成にアクセスできることに注意してください。

最後に、経験からの重要な注意:構成をできるだけ小さくしてください。.NET では、.configファイルは構成に最適な場所です。これは、開発者がそこを見るように既に訓練されている場所だからです。しかし、エンタープライズ アプリケーションでは、各開発者が柔軟なコンポーネントをコーディングする必要があるため、制御不能になる可能性があります。これは貧弱なアーキテクチャの匂いです:異なる構成で使用されることがわかっているものだけを構成可能にします。

展開のたびにカット アンド ペーストされたセクションを削除するよりも、後で実際に必要なときに構成セクションを追加する方が簡単です。このような構成は、必要のない柔軟性のために過度に設計されている可能性があります。

于 2013-04-14T10:43:29.617 に答える