N 层应用程序配置检索/存储

Question

在使用 ASP.NET MVC (C#) 开发我的网站时，我使用了领域驱动设计 (N-Tier) 作为架构。

我想知道如何为我的应用创建设置/配置（不使用数据库表）。

我首先想到了 .settings 文件，但我仍然不确定这是否是正确的方法（例如，它应该放在哪里？）。因此，我在 web.config 中添加了配置值，然后在核心层中创建了一个 t4 模板，该模板从 web.config 生成 AppConfigurationManager，以免破坏 DDD 设计。

我仍然认为我使用了不好的方法。

那么，在处理领域驱动设计时，您建议如何保存配置？

我的 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
        <#
        }
        #>
    }
}

Answer 1

从域层访问配置有时适用于域服务，但它会使服务难以单独测试。

顺便说一句，您应该避免从实体和值对象进行此类访问。

更好的方法是读取基础设施层中的配置并通过域对象中的构造函数参数注入所需的值。请注意，工厂和存储库是基础架构的一部分，因此如果需要，它们可以访问此类配置。

最后一个重要的提示，根据经验：保持配置尽可能小。在 .NET 中，.config 文件是配置的最佳位置，因为它是开发人员已经接受过培训的地方。但是在企业应用程序中，它们可能会变得不受控制，因为每个开发人员都希望编写灵活的组件。这是一种糟糕架构的味道：只将您知道的可配置内容用于不同的配置。

稍后在实际需要时添加配置部分比删除在每次部署时剪切和粘贴的部分更容易。此类配置可能被过度设计以获得他们不需要的灵活性。