【问题标题】:where to write the connection string ? in app.config or in web.config?在哪里写连接字符串?在 app.config 或 web.config 中?
【发布时间】:2014-06-15 08:02:50
【问题描述】:

我正在开发 MVC 应用程序。 我的应用程序中有两个项目。 一个是包含控制器和视图的 MVC 应用程序,第二个是 DataLayer 项目。

我对在哪里写入连接字符串感到困惑,因为在发布应用程序时它需要 web.config 文件,并且我从 DataLayer 项目中获取数据,所以我应该在 app.config/Web.config 中添加连接字符串数据层项目?

另外,想知道 app.config 和 web.config 的用途和区别是什么?

【问题讨论】:

标签: c# asp.net asp.net-mvc


【解决方案1】:

连接字符串位于 Web.config 中。默认情况下,它将查看执行程序集的配置并忽略引用程序集的配置文件。

可以在设计时使用引用程序集的配置文件。例如,如果您在数据层程序集中使用实体框架,它会将用于从数据库构建模型的连接信息存储在 app.config 中。

当我到达 web 项目将要运行并通过数据层访问数据的点时,我通常只是将该连接信息复制到 web.config。

【讨论】:

  • DataLayer 将使用 web.config 文件中的连接字符串?
  • 提示:如果您在设计时不使用它(例如,使用 EF Code-First 时),您甚至可以将其从 app.config 中删除并保留在 web.config 中网站项目的
【解决方案2】:
  • Web.Config 用于 asp.net 网络项目/网络服务。
  • App.Config 用于 Windows 窗体、Windows 服务、控制台 应用程序和 WPF 应用程序。

数据层项目Web.config中添加您的连接字符串

【讨论】:

  • 好的,所以我将在 datalayer 的 WebConfig 文件中添加连接字符串。但是发布应用程序呢?它需要 MVC 项目的 web Config 而不是 dataLayer 项目...
  • 类库中没有web.config。
【解决方案3】:

每个项目在创建时都附带一个配置文件。通用类库有一个名为app.config 的通用类库。 Web 项目更具体,因此其文件名为web.config,并带有特定于 Web 的参数。它们都具有相同的目的。

您面临的问题是默认情况下仅部署了可执行项​​目的配置文件(web.config)。您有几个选择:

  1. 将您的连接字符串添加到 web.config 并将其传递给您的数据层。这很简单(最常见),但会将配置信息与您的数据层项目分开。
  2. 让您的数据层使用System.Configuration.ConfigurationManager 读取web.config。这使您无需将数据传递到数据层,但会产生强依赖性(如果没有正确格式化的 web.config 文件,您的数据层将无法工作)。
  3. 将 app.config 部署为 XML 内容并编写自定义代码,以便您的数据层可以读取它。这是更多的工作,但它会从 Web 配置中获取您的数据配置。
  4. 对#2 稍作改动,您可以在web.config 中创建一个名为“dataLayer”的custom config section。这可以通过System.Configuration.ConfigurationManager 阅读。我更喜欢这种方法,因为它似乎是一个很好的平衡。您在“默认”配置文件中有一个自定义的强类型配置部分。

这个related question 也有一些很好的信息。

【讨论】:

  • 我已添加参考。 MVC项目中的datalayer,如何传递给datalayer?
  • Here's how 你是从 web.config 中读到的。然后将其作为字符串传递给数据层中的方法或构造函数。
【解决方案4】:

我将首先回答您的问题,然后继续讨论 IMO 更重要的考虑因素。对于这个特定的用例,我更喜欢 DI 模式,其中消费者告诉提供者连接字符串是什么。这使您的数据层与数据库无关,并允许它与满足其合同的任何数据存储进行通信。简而言之,由于您的 MVC 项目是数据层的消费者,因此连接字符串存储在 web.config 中。 BUT IT IS STORED ENCRYPTED!!!

那么,这里实际上存在一个比您实际编写连接字符串的位置更深的问题,那就是在您的消费代码和配置存储之间建立一个抽象。如果您这样做,那么您存储配置值的位置基本上就变得无关紧要了。

我总是在每个层(项目)中创建一个配置类,该类提供在该层中使用的配置值。这提供了几个好处:

  1. 它允许在使用强类型值时使用它们。如果你的配置值是一个int,你得到一个int,你消费的时候不需要转换。
  2. 它允许默认值可能已被无意中遗漏在配置文件中。这使您的代码更加健壮。
  3. 它允许您灵活地存储值。您可以将一些值放在配置文件中,将其他值放在数据库中,还可以从远程 Web 服务中获取更多值。如果您决定更改商店,您只需在一个地方编辑代码 - 而不是每个地方都会消耗价值。
  4. 随着解决方案的增长和项目的添加,该模式可以很好地扩展并保持配置隔离。
  5. 它会从您的代码中删除魔术字符串。

而不是下面的,它有一个讨厌的魔法字符串:

return System.Configuration.ConfigurationManager.AppSettings["DefaultUserName"];

你会写

MyApp.Configuration.DefaultUserName

这是一个非常基本的实现示例,它返回一个强类型(在本例中为 DayOfWeek)。它有一个辅助方法来帮助您抽象从商店拉出的行为。如果您需要包含多个商店,此方法将采用 T 类型的泛型,其中 T 是商店的类型。在下面的简化示例中,它只是从配置文件中提取:

 public class Configuration
    {
        private const DayOfWeek FailsafeDefaultDayOfWeek = DayOfWeek.Saturday;

        /// <summary>
        /// A default for the day of week
        /// </summary>
        public static DayOfWeek DefaultDayOfWeek
        {
            get
            {
                string dayOfWeekString = GetSettingValue("DefaultDayOfWeek");

                try
                {
                    return (DayOfWeek)Enum.Parse(typeof(DayOfWeek), dayOfWeekString);
                }
                catch (Exception)
                {
                    // If someone screws up and forgets to include a value, or the value cannot be cast:
                    return FailsafeDefaultDayOfWeek;
                }
            }
        }

        /// <summary>
        /// Helper method to easily pull a value from a configuration store.
        /// </summary>
        /// <param name="settingName"></param>
        /// <returns></returns>
        private static string GetSettingValue(string settingName)
        {
            try
            {
                return System.Configuration.ConfigurationManager.AppSettings[settingName];
            }
            catch (Exception)
            {
                throw new MissingConfigurationValueException(settingName);
            }
        }
    }

【讨论】:

    猜你喜欢
    • 2013-03-04
    • 2014-05-22
    • 2011-08-13
    • 2016-09-22
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-02-24
    • 2013-06-22
    相关资源
    最近更新 更多