基础才是重中之重~用好configSections让配置信息更规范

对于小型项目来说,配置信息可以通过appSettings进行配置,而如果配置信息太多,appSettings显得有些乱,而且在开发人员调用时,也不够友好,节点名称很容易写错,这时,我们有几种解决方案

1 自己开发一个配置信息持久化类,用来管理配置信息,并提供面向对象的支持
2 使用.net自带的configSections,将配置信息分块管理,并提供实体类,便于开发人员友好的去使用它

本文主要说说第二种方案,它由实体类,实体类工厂及配置文件三个部分,看代码:

实体类设计:

namespace Configer
{
    /// <summary>
    /// 网站信息配置节点
    /// </summary>
    public class WebConfigSection : ConfigurationSection
    {
        /// <summary>
        /// 网站名称
        /// </summary>
        [ConfigurationProperty("WebName", DefaultValue = "", IsRequired = true, IsKey = false)]
        public string WebName
        {

            get { return (string)this["WebName"]; }
            set { this["WebName"] = value; }
        }
        /// <summary>
        /// 网站域名
        /// </summary>
        [ConfigurationProperty("DoMain", DefaultValue = "", IsRequired = true, IsKey = false)]
        public string DoMain
        {

            get { return (string)this["DoMain"]; }
            set { this["DoMain"] = value; }
        }

    }
}

实体工厂类设计,主要用来生产实体配置信息

namespace Configer
{
    /// <summary>
    /// 网站配置信息工厂
    /// </summary>
    public class WebConfigManager
    {
        /// <summary>
        /// 配置信息实体
        /// </summary>
        public static readonly WebConfigSection Instance = GetSection();

        private static WebConfigSection GetSection()
        {
            WebConfigSection config = ConfigurationManager.GetSection("WebConfigSection") as WebConfigSection;
            if (config == null)
                throw new ConfigurationErrorsException();
            return config;
        }
    }
}

而最后就是.config文件了,它有configSections和指定的sections块组成,需要注意的是configSections必须位于configuration的第一个位置

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <section name="WebConfigSection" type="Configer.WebConfigSection, test"/>
  </configSections>
  <connectionStrings>
    <add name="backgroundEntities" connectionString="metadata=res://*/Model1.csdl|res://*/Model1.ssdl|res://*/Model1.msl;provider=System.Data.SqlClient;provider connection string=&quot;Data Source=.\sqlexpress;Initial Catalog=background;Integrated Security=True;MultipleActiveResultSets=True&quot;" providerName="System.Data.EntityClient" />
  </connectionStrings>

  <WebConfigSection WebName="占占网站" DoMain="www.zhanzhan.com"  />
  <appSettings>
    <add key="site" value="www.zzl.com"/>

  </appSettings>
</configuration>

以上三步实现后,我们就可以调用了,呵呵

  static void Main(string[] args)
   {
     Console.WriteLine(System.Configuration.ConfigurationManager.AppSettings["site"]);
     Console.WriteLine(WebConfigManager.Instance.DoMain);
     Console.WriteLine(WebConfigManager.Instance.WebName);
   }

结果如下:

时间: 2025-01-01 20:50:08

基础才是重中之重~用好configSections让配置信息更规范的相关文章

基础才是重中之重~再说面向接口的编程

之前在我的文章中有对接口进行过讲解,但感觉讲的还是不够清晰,不够利针见血,这次我把面向接口的编程里,自认为比较核心的两点说一下: 接口详细介绍请看我的这篇文章 基础才是重中之重~为什么C#有显示实现接口 一切依赖于抽象,而不是实现 多个接口相同的行为,被一个对象实现 #region 多个接口相同的行为,被一个对象实现(一切依赖于抽象,而不是实现) interface IPainter { void Draw(); } interface ICowBoy { void Draw(); } clas

基础才是重中之重~这时应该用泛型方法了

回到目录 泛型方法:是一个抽象的概念,将批量具有共性的操作进行抽象,使用泛型类型来表示这个方法,实现这些类型的方法具有相同的逻辑,而唯一不同的是,它们的类型,即类型在泛型方法里是个变量,这话感觉是用肺说出来的,呵呵! 今天在做开发时,遇到了这个问题,最后重构了自己的代码,重构后,使用了泛型方法,感觉代码美丽多了 没用泛型方法前 /// <summary> /// 更新老师与学生的关系 /// </summary> /// <param name="list"

C# 基础才是重中之重~对象的生与死

为何要写 之所以写这篇文章,完全是因为学生们在实际开发中遇到的问题,一个对象占用的内存空间总不被释放,导致系统内存不断攀升,其最主要原因是我们对“对象的生与死”不清楚,或者从来没有认真去考虑过这件事,确实一个对象在被声音,初始化,使用或者最后被系统回收,整个的过程与我们关系确实不大,我们开发人员直接用就行了,对于C#这种托管语言你没必要去自己回收它,但有时,我们多了解一点系统的回收机制,对我们的程序还是很有好处的. 对象的种类(根据作用域) 1 类对象,静态对象,使用static修饰符进行声明,

基础才是重中之重~对象的生与死

回到目录 为何要写 之所以写这篇文章,完全是因为学生们在实际开发中遇到的问题,一个对象占用的内存空间总不被释放,导致系统内存不断攀升,其最主要原因是我们对“对象的生与死”不清楚,或者从来没有认真去考虑过这件事,确实一个对象在被声音,初始化,使用或者最后被系统回收,整个的过程与我们关系确实不大,我们开发人员直接用就行了,对于C#这种托管语言你没必要去自己回收它,但有时,我们多了解一点系统的回收机制,对我们的程序还是很有好处的. 对象的种类(根据作用域) 1 类对象,静态对象,使用static修饰符

基础才是重中之重~泛型类的静态构造方法可不是只执行一次呀

回到目录 最近做了一个数据库的读写分离项目,使用到了DbCommand拦截器,在程序开发过程中没有发现什么特别的问题,而当开发完成后,在进行测试阶段时,一个偶然的机会让我发现了,原来我的拦截器注入不只是注入一次,而是每种类型的仓储都会注入一次,这个问题事实上是相关严重的一件事,如果你的拦截器处理逻辑很多,那么,这将是非常消耗性能的. 原因,静态构造方法对泛型类不是唯一的,而是相互独立的 public abstract class DbContextRepository<TEntity> : I

基础才是重中之重~Dictionary&lt;K,V&gt;里V的设计决定的性能

回到目录 字典对象Dictionary<K,V>我们经常会用到,而在大数据环境下,字典使用不当可能引起性能问题,严重的可能引起内在的溢出! 字典的值建议为简单类型,反正使用Tuple<T> 字典的键在查找时,时间复杂度为O(1),性能不会有任何问题,所以不要愿望它 下面代码是对500万的字典进行测试,首先赋值,然后取出一个随机机,性能在毫秒级 static void Draw() { int count = 5000000; Console.WriteLine("test

基础才是重中之重~Emit动态构建方法(参数和返回值)

回到目录 对于Emit我们知道它的可以动态构建程序集,类型,方法,属性等,或者说只要手动使用C#创建的东西使用Emit也都可以动态创建它们,Emit由于它的特别之处,所以在很多领域得到了广泛的应用,像最近比较火的AOP技术,它最核心的功能就是方法拦截了,我们使用Emit也是可以实现方法拦截功能的,详细可以看大叔这篇文章<Lind.DDD.Aspects通过Plugins实现方法的动态拦截~Lind里的AOP>. 有参数,没有返回值的方法构建与调用 [TestMethod] public voi

基础才是重中之重~网站bin目录下的程序集自动加载

回到目录 网站bin目录下的程序集一般由系统项目,项目引用的外部DLL及外挂DLL组成,它们在网站运行时会自动加载,这一点很重要,项目本身DLL及项目引入的DLL会自动加载,这没有问题,而外挂在bin目录的DLL也会自动加载,这很重要,因为,它可以使我们的应用程序更加灵活,在开发通用功能上,也显得扩展性更强! 一个例子,比如一个HttpModule,它是一个通用的功能,向页面添加一些缓存过期的共用信息,这对于你所有网站都是共用的,这时,可以建立一个HttpModule项目,它代码可能是这样 na

基础才是重中之重~多线程的代价~我的内存都被吃了!

回到目录 异步操作是.net4.5推出的新名词,事实上,这东西早就有了,它归根结底是通过线程池来实现的,即将一个大任务分成多个小任何块,每个线程并行处理其中的一个,完成后再把结果告诉主线程,在.net4.5推出后,这种技术得到了封装,让开发人员实现起来更加方便了,但是,并发(导步,多线程)并不是在哪里都适用的,使用不当,可能出现很多严重的后果! 看我的程序,这家伙已经占到了2.6G的内存空间了,很可怕吧! 出现这种问题的原因就是我没有把线程这东西搞清楚,在一个调用密集的环境里,使用了多线程,要知