很早的时候就开始写一个configuration,但是发现net自带的configuration有些地方让人搞不明白

 

看下面的代码  app.config

 

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
   
    <section name="myCustomerSectionA" type="System.Configuration.NameValueSectionHandler"/>
   
    <section name="myCustomerSectionB" type="ConfigurationDemoII.CustomerSectionHandlers,ConfigurationDemoII" />
  
  </configSections>

  <myCustomerSectionA>
    <add key="myKeyA" value="myKeyAValueA" />
    <add key="myKeyA" value="myKeyAValueB" />
    <add key="myKeyB" value="myKeyBValueA" />
    <add key="myKeyB" value="myKeyBValueB" />
  </myCustomerSectionA>

  <myCustomerSectionB>
    <add key="myKeyA" value="myKeyAValueA" />
    <add key="myKeyA" value="myKeyAValueB" />
    <add key="myKeyB" value="myKeyBValueA" />
    <add key="myKeyB" value="myKeyBValueB" />
  </myCustomerSectionB>
 

</configuration>

 

app.cs

 

using System;
using System.Collections;
using System.Collections.Generic;
using System.Collections.Specialized;
using System.Text;
using System.Xml;
using System.Configuration;

namespace ConfigurationDemoII
{
    class Program
    {
        static void Main( string[] args )
        {
            try
            {
                TestSysNameValueCollection();
                Console.WriteLine( "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~" );
                TestMyNameValueCollection();
            }
            catch( Exception ex )
            {
                Console.WriteLine( ex.Message );
                Console.WriteLine( ex.StackTrace );
            }
        }

        private static void TestSysNameValueCollection()
        {
            NameValueCollection nvc = (NameValueCollection)ConfigurationManager.GetSection( "myCustomerSectionA" );
            foreach( string key in nvc.AllKeys )
            {
                Console.WriteLine( key );
                Console.WriteLine( nvc[key] );
            }
        }

        private static void TestMyNameValueCollection()
        {
            NameValueCollection nvc = (NameValueCollection)ConfigurationManager.GetSection( "myCustomerSectionB" );
            foreach( string key in nvc.AllKeys )
            {
                Console.WriteLine( key );
                Console.WriteLine( nvc[key] );
            }
        }
    }

    class CustomerSectionHandlers : IConfigurationSectionHandler
    {

        #region IConfigurationSectionHandler 成员

        object System.Configuration.IConfigurationSectionHandler.Create( object parent, object configContext, System.Xml.XmlNode section )
        {
            NameValueCollection col = new NameValueCollection();

            foreach( XmlNode childNode in section.ChildNodes )
            {
                XmlElement root = (XmlElement)childNode;
                if( root.Name == "add" )
                {
                    string key = root.GetAttribute( "key" );
                    string value = root.GetAttribute( "value" );
                    col.Add( key, value );
                }
                else if( root.Name == "remove" )
                {
                }
                else if( root.Name == "clear" )
                {
                }
            }

            return col;
        }

        #endregion
    }
}

 

 

 

运行的结果 

 

myKeyA
myKeyAValueB
myKeyB
myKeyBValueB
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
myKeyA
myKeyAValueA,myKeyAValueB
myKeyB
myKeyBValueA,myKeyBValueB
Press any key to continue . . .

 

能看到什么不同么， Sys自带的namevaluecollection好像把后面新加入的同一个key的信息冲掉了，如果是configuration本身就是这么设计的，那么为何要用NameValueCollection这个容器呢?

 

我在cnblog的几篇介绍configuration的文章中并没有找到相关的信息  http://msdn.microsoft.com/msdn-online/shared/components/ratings/ratings.aspx?ContentID=_978498&HideDiscuss=1里面也没有这一块类似的介绍

 

OK, 打开Refelect看看吧  哦，  

internal static object CreateStatic(object parent, XmlNode section, string keyAttriuteName, string valueAttributeName)
{
      ReadOnlyNameValueCollection collection1;
      if (parent == null)
      {
            collection1 = new ReadOnlyNameValueCollection(new CaseInsensitiveHashCodeProvider(CultureInfo.InvariantCulture), new CaseInsensitiveComparer(CultureInfo.InvariantCulture));
      }
      else
      {
            ReadOnlyNameValueCollection collection2 = (ReadOnlyNameValueCollection) parent;
            collection1 = new ReadOnlyNameValueCollection(collection2);
      }
      HandlerBase.CheckForUnrecognizedAttributes(section);
      foreach (XmlNode node1 in section.ChildNodes)
      {
            if (!HandlerBase.IsIgnorableAlsoCheckForNonElement(node1))
            {
                  if (node1.Name == "add")
                  {
                        string text1 = HandlerBase.RemoveRequiredAttribute(node1, keyAttriuteName);
                        string text2 = HandlerBase.RemoveRequiredAttribute(node1, valueAttributeName, true);
                        HandlerBase.CheckForUnrecognizedAttributes(node1);
                        collection1[text1] = text2;
                  }
                  else
                  {
                        if (node1.Name == "remove")
                        {
                              string text3 = HandlerBase.RemoveRequiredAttribute(node1, keyAttriuteName);
                              HandlerBase.CheckForUnrecognizedAttributes(node1);
                              collection1.Remove(text3);
                              continue;
                        }
                        if (node1.Name.Equals("clear"))

 

还是偷懒一下，等着牛人来回答吧

 

过往的牛人， 请留下高见

 

 

前段时间偶尔在msn上被人问起GC，自己也是不明白，整理了一下不明白的问题。为以后学习做准备

using System;
using System.Collections.Generic;
using System.Text;

namespace GCDemo
{
    class Program
    {
        static void Main( string[] args )
        {
            MyClassTemp temp= new MyClassTemp();
            //MyClassAdapter temp = new MyClassAdapter();

            GCCall();           
        }

        private static void GCCall()
        {
            Console.ReadLine();

            Console.WriteLine( "GC START" );
            GC.Collect();
            Console.WriteLine( "GC END" );

            Console.ReadLine();
        }
    }

       class MyClassTemp
    {
        public MyClassTemp( )
        {
            Console.WriteLine( "MyClassTemp is Creating" );
        }

        ~MyClassTemp( )
        {
            Console.WriteLine( "MyClassTemp is Destroying" );
        }
    }

    class MyClassAdapter
    {
        public MyClassAdapter( )
        {
            MyClassTemp temp = new MyClassTemp();
        }
    }
}

 

-----------------------------------------------------------------

如果把main函数中的代码修改如下 那么得到的结果将会是不同的 

//MyClassTemp temp= new MyClassTemp();
MyClassAdapter temp = new MyClassAdapter();

 

JIT编译main函数，个人感觉好像是把Main函数的所有引用（这里专指引用到heap上的对象）放到root中

 MyClassTemp temp= new MyClassTemp(); 这个temp也被放入。那么后来在main函数中调用GC的时候，temp的引用仍然在root中，所以temp并不被GC，而关闭这个控制台程序的时候，temp被GC掉。

 

如果使用这段代码 MyClassAdapter temp = new MyClassAdapter();  这个时候main中调用了自函数，此子函数调用结束之后（子函数栈和堆退出了） 这个时候temp这个引用应该是可以从root上移除了，GC的时候，temp被GC.

 

关乎GC，说得比较清楚地只有jeffrey richer的《Applied Microsoft .Net Framerok Programming》，没有别的书作对照和参考，我也不能很好的理解，如果理解的有错误的地方，望个位路过的留个记号，多多指教。

在这里做个记号，没有系统的接触过，先做个记号，以后慢慢来吧。

 

每一个虚拟目录应该是对应着一个AppDomain 的， 而每一个AppDomain里面应该是有很多的Application实例，这些实例的创建应该是在用户第一次请求一个Page被创建的。 

 

那么同一个Page的多个请求，是使用一个App还是每一个用户都建立单独的App----------汗，这点搞不明白。   

 

恩  或许是这个样子的。 

App是一个Instance  当一个request收到的时候， 相应的App就会被建立，

这个App就被pool 因为App的创建应该是比较好费资源的（parse 和 compily 特别是这种parse 如果没有pool 应该是非常费劲 ）    

接着authentication authorization 和 Session 的module 依次工作 当这个请求结束的时候  虽然意义上这个App的生命期已经结束了 但是实际上它在pool里面 

至于request的Session 应该是放到一个别的地方（比如说SessionState进程） Session 的module会在工作的时候根据key取道相对应的value

-----------------------------------------------------------------------------------------------------

----------至于request的Session 应该是放到一个别的地方（比如说SessionState进程）--------

也就是在这个地方  如果使用的是inproc （我个人感觉这个inproc应该就是这个app） 那么当一个用户的reqeust处理完后是不能把App释放了的 因为session还在里面阿  这个要一直活到Session实效为止  而且不同用户访问同一个page的时候 也不能已经创建好的App去应付这个新的请求阿  因为他们的Session是不一样的阿   汗 

-----------------------------------------------------------------------------------------------------

不管是别的用户还是仍旧是当前用户  如果发送出对相同的Page的请求  App被从pool中取出 周而复始

 

也就是说应该是每一个Page都会有一个App  而不同用户访问请求相同的Page的时候 访问的都是一个App(但是这个App的一些冬冬是不同的 比如说Session什么的   其实App本身是个动态的概念 但是因为pool  所以就~~~~) 

 

 

这个概念和Remoting的为每一个请求创建一个app和都是用一个app处理所有的请求有些差别  汗 不知道remoting 所以这些事情搞不明白

如果有人能够给我讲讲asp或者是java中的服务器端模型 应该能加深理解  后悔大学里怎么没有学习一下asp

 

个人感觉UI使用html不断的回来回去的实在是滥  但是相对应的asp.net确实做得如此的棒  断开连接和使用pool这些都很漂亮 更要命的是 Parse和complier  当然这个东西同时也是学习asp.net的最大的障碍   我不知道怎么才能找到最终生成的appClass代码和PageClass代码

VS03中在还能看些简单的  VS05都不知道怎么做了

 

asp.net比较滥的地方是那些control  他们在设计其中的展现和他们的功能相互交错在一起  即使使用的是Attribute 但是感觉还是掺在一起了  要想做一个完全第三方的ide还真的比较难了  html把展现和数据掺和到一起 死掉了 asp.net的control把功能和定制掺和到了一起 后果如何 慢慢看~~~~~~~~~~~

 

 

文章地址: http://www.west-wind.com/presentations/howaspnetworks/howaspnetworks.asp

博客园已经有人在做翻译了。

 

这篇文章着重讲述了 isapi 到 httphandler 处理过程的一些细节

 

对于这方面讲述的比较好的中文书籍有：《asp.net服务器控件组件开发》 和 《asp.net组件程序设计技术内幕》  -------- 可能会有别的书 好像是有一本叫什么《asp.net揭秘》 绿色的封面 但是好像是很厚 我怕会有很多地方讲述如何使用控件 在书店的时候就没有翻过

 

但是 《asp.net服务器控件组件开发》 对于isapi 到 httphandler 处理过程讲的很简单 因为做一个servercontrol主要是要使用httphandler后面的东西   而《asp.net组建程序设计技术内幕》中  黄忠成老先生好像是表达不在行 弄得我一直是云里雾里 以至于这本书在我手里一年多了 我一直都没有看过

 

个人认为一个高效率的portal可能是安插了一个新的httpmodule来对付自定义的UI 而不可能是在httphandler之后作一些动作

 

但是ms的sps大概在什么地方实现我个人不清楚 因为本人的asp.net水平实在是不怎么样 ---------- 恩 仅仅是停留在会使用控件的层次

 

 

先做个记号 有了别的心得在继续补充

做一个新的系统，首先要对系统需要实现的功能明确，然后开始对每一块要实现的功能作技术实现的研究，等所有的技术点都解决得差不多的时候。就需要设计架构（准确地说没有达到的架构规模，而仅仅是模块的逻辑关系），一般来说，模块的功能是不变的，而功能的实现是变化的，找准系统中不变和可变的部分，这个是设计的重中之重。

 

       这些是对于很有经验的系统架构师来说，想我这种水平的人就做不得到，我一般采取的方法是，先使用最简单的技术对系统做一个模型（这个模型并不困难，每一个技术点的代码组合一下就差不多了），然后在模型的基础上重构，说白了就是从新写组织代码，这个时候需要注意的是往往重构代码的时候会沉浸在代码重而忽略了。

 

       LCEIP中可能存在的变化

1．  SSO。SPS的新版本实可以选用From验证，甚至说这个From的数据完全可以读取自己数据库里的表而不是SPS提供的API，这个一个接口就可以搞定，同一个系统使用的凭证信息存放在SPS和存放在数据库里都没什么问题了。但是不同系统的验证信息可能所需的数量和类型都是不一样的，这个才是系统变化中最要命的部分。可以做一个接口，接口里面包含一个事件，时间的参数有一个SignOnSuccess的标志，不同系统中的登陆都注册此事件，但是这个接口抽象地层次是如此之高，估计意义不会很大。(还有该死的SPS只能存放5个字段，当然可以把这五个字段映射到相应的表中用来扩充。这是一个多么令人恶心的解决方法啊)。

2．  WebPart。Part的功能就是展现，这个是不变的，Part的实现可以有很多种变化，GS3.2的Part和GS3.0的Part实现方式完全不一样，而Web方式的Part也是完全不一样的，这个变化的封装不应该在WebPart中而应该在ToolPart中。第二点的变化就是如果把继承SPS中的WebPart的修改为继承.net2.0的WebPart，代码不作修改或者说仅仅需要做少量的修改就能继续正常工作。

 

 写到这个地方做个备份同时也希望各位路过的大虾都给个意见

Office SharePoint Server 2007 !（转载 Kaneboy's Bloy）

微软正式将Office12命名为了Office 2007，而SharePoint产品的名称则是：Office SharePoint Server 2007（OSS2007）。呵呵，没错，“Portal”这个词已经从产品名称中去掉了，原因就是，下一代的SharePoint Server已经不仅仅是一个企业门户产品了！除了门户，它能干啥呢？嗯，比如：

企业资源搜索引擎

没错，如果你用过SPS2003，那么一定对SPS强大的搜索能力印象深刻。SPS能够以爬网的方式，对企业内部的网站（当然，如果愿意，你一样可以让SPS去爬Internet上的站点，比如新浪新闻...）进行全面的检索，当然，对文档库、共享文件夹中的文档进行全文索引，也是它的拿手好戏！OSS 2007对搜索功能进行了大幅的改进，不但提高了搜索效率和准确性，还增加了更多的可搜索内容。

如果企业中已经存在不少的内部网站、OA系统、文档管理中心...难道会不需要一个强大的搜索引擎能够对所有这些进行搜索吗？我们完全可以仅仅把SharePoint用做企业内部资源的一个搜索引擎，让我们的用户在上面能够搜索到企业内部所有的信息！

Blog/Wiki

OSS2007内置了Blog和Wiki站点模板，通过OSS2007，我们可以迅速在公司内创建Blog站点和Wiki站点。

Workflow Server

在Office2007中，将内置对Workflow的支持，比如，你可以在Word里面直接用当前文档启动一个定义好的流程，然后在Outlook里面看到自己的流程任务。而Office2007的Workflow中心，就是SharePoint Server。

 

 

图片是从网上down下来的office12 但是没有发现有sharepointserver的影子 估计不在这张盘中 郁闷

等待着ms快点出来