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

时间:2013-04-14 00:13:17

标签: c# asp.net-mvc domain-driven-design n-tier-architecture

使用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
        <#
        }
        #>
    }
}

1 个答案:

答案 0 :(得分:2)

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

你应该避免实体和价值对象的这种访问,顺便说一句。

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

最后一个重要的注意事项,经验丰富:保持配置尽可能小。在.NET中,.config文件是配置的最佳位置,因为开发人员已经接受过培训,可以在那里查看。但在企业应用程序中,由于每个开发人员都希望编写灵活的组件,因此他们可能会不受控制地增长。这是一种糟糕的架构气味:只能配置您知道的用于不同配置的内容。

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

相关问题