博客园-LoveCherry

.NET 4.0改进（一）

lovecherry — Thu, 20 Aug 2009 06:23:00 GMT

阅读: 1178 评论: 5 作者: lovecherry 发表于 2009-08-20 14:23 原文链接

核心服务

大部分的新特性都是围绕自定义和扩展来的，原先不能自定义的东西现在可以自定义了，可以自己扩展了，然后把自己的组件在web.config中配置即可应用我们自己的组件。

Web.Config精简

.NET框架4.0中会把大部分配置放到machine.config中，这样在web.config中甚至可以一行代码都不写。

自定义输出缓存策略

输出缓存对于改善性能有很大好处，在ASP.NET 4.0中可以自定义输出缓存的策略，比如把输出保存在磁盘中，外部的memcached服务中等等。甚至还可以定义一些高级规则，比如为A页面使用A输出缓存策略来把数据保存于内存中，为B页面使用B输出缓存策略来把数据保存于磁盘中。

type="Test.OutputCacheEx.DiskOutputCacheProvider, DiskCacheProvider"/>

自启动的应用程序

ASP.NET 4.0和IIS 7.5配合可以设定一个预处理的Provider，这样在应用程序池启动或回收后IIS会自动调用这个Provider中的代码来处理，处理完毕之后才接受请求。

type="MyNamespace.CustomInitialization, MyLibrary" />

永久重定向

如果使用Response.Redirect的话，返回302状态，客户端再发送一次请求到新的地址，在ASP.NET 4.0中提供了RedirectPermanent方法来永久重定向到某个地址。客户端或搜索引擎遇到301状态码会保存这个永久重定向地址，以后会直接访问定向后的地址，节省了一次往返。

压缩会话数据

如果使用进程外Session或SQL Server保存Session的话，会话数据需要进行序列化和反序列化，ASP.NET 4.0提供了使用GZIP压缩会话数据的特性来缩小会话数据流的大小。

mode="SqlServer"

sqlConnectionString="data source=dbserver;Initial Catalog=aspnetstate"

allowCustomSqlDatabase="true"

compressionEnabled="true"

URL规则

在ASP.NET 4.0中可以自定义访问路径以及QueryString的长度，并且还可以设定路径中无效的字符，而在以前这些都不是可以定制的。

自定义RequestVaidation

RequestValidateion虽然可以有效防止XSS注入等，但在以前验证规则是不可以自定义的，很多时候我们觉得这个规则太严格了只能关闭这个功能。在ASP.NET 4.0中可以自定义类来实现自己的验证规则。

对象缓存

System.Web.Caching.Cache大家很熟悉，甚至有的时候编写Windows和Windows服务程序的时候也会引用System.Web.dll来使用这个Cache功能。在4.0中这个功能在System.Runtime.Caching.dll中会有新的实现，并且也会更强大。

自定义Encoding

URL Encoding/HTML Encoding都是很常用的功能，在ASP.NET 4.0中我们可以继承System.Web.Util.HttpEncoder来自定义编码规则。

AppDomain级别的性能检测

如果在一个进程中运行多个网站的话我们可能希望能监视到每一个网站的性能，在ASP.NET 4.0中我们可以开启AppDomain级别的性能检测。

评论: 5　查看评论　发表评论

最新新闻：
· 美调查公司称苹果iPad配件成本最低219美元(2010-02-10 17:20)
· 摩尔庄园：儿童生意密码(2010-02-10 17:15)
· Facebook与美国在线合作整合AIM动态功能(2010-02-10 16:41)
· NDepend 3.0已与Visual Studio集成(2010-02-10 16:17)
· Ruby in Steel 1.5发布，去除IronRuby支持(2010-02-10 16:14)

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

到底怎么样的面试才是最公平的才能找到合适的人又不产生误判

lovecherry — Wed, 29 Jul 2009 09:16:00 GMT

阅读: 4231 评论: 55 作者: lovecherry 发表于 2009-07-29 17:16 原文链接

一般来说，技术面试会是如下集中形式的一种或是多种的组合：

1、笔试，做题目

2、面对面交流

3、上机编程

其实我个人不喜欢笔试，感觉笔试关注的点太细了，更不喜欢上机编程，觉得这种方式的面试并不是很尊重面试者，比较喜欢轻松的面对面的交流。我面试过很多人也被很多人面试过，越来越感觉其实任何一种形式的面试都有其优点和缺点。

在之前公司，我面试别人都是采用1和2组合的方式，候选人会先做一套题目，这样对每一个人都有一个评判的标准，然后再会面对面聊1个小时。而现在公司，没有笔试，直接面对面随机问一些问题，所谓随机就是每次问的问题都不一样，或许是面试者感兴趣的技术又或许是自己随手想到的问题。

感觉几乎没有人能得到自己的认可，我不觉得这是因为他们的问题，我觉得这是我的问题，可能这种形式的面试不是最合适的。因为.NET开发的技术实在是太多了，每次半个小时左右的面试，我只能在ADO.NET、ASP.NET、IIS、C#、CLR、T-SQL、SQL-SERVER、WINFORM、架构、性能、设计模式、OOP、HTML、CSS、JS、框架、分布式开发等知识点上各问一个问题，比如：

l HTTPMODULE/HTTPHANDLER

l IIS每一个版本的增强

l 值类型引用类型的区别

l T-SQL如何分页

l SQL SERVER索引和死锁

l 如何开新的线程，如何确保线程安全

l 什么是JSON、XMLHTTP

l 等等等等。

正因为如此，一个问题回答的不正确，我只能认为候选人在这方面是不擅长的，很怕作出错误的判断，所以有的时候问的问题尽量是这方面最最基本的问题。而且我都会在最后问两个编程的题目，一个是C#的，一个是T-SQL来看看候选人的实战能力，因为确实很多人并不会去研究很多基础的东西，或是表达能力有限，知道这个东西会用但却不知道用专业的术语来解释。也确实遇到过误判的情况，有的人在面试的时候什么都说不出，但来了之后却能胜任，学习能力也很强。有的时候想想如果有笔试的话会公平很多，有的是确实不善于表达会紧张，甚至有上机面试的话能要求候选人直接看看我们的项目代码，如果能在1个小时之内把项目基本的运作逻辑搞清楚的话应该能力不错。不知道大家是怎么看这个问题的。

最后，我想从面试官的角度来说几个面试技巧：

l 技术再好，英语再好也要态度诚恳，有的人觉得自己英语很好，想表现一下，其实对于面试官来说可能并不在乎这个，他只是来面试你技术的

l 简历上把真正精通的技术再写精通，否则面试官问了你精通的技术你回答不出来，那么他可能会觉得你其他精通的技术也不精通，或者说也是这个水平的

l 不怎么熟悉的技术就直接说不知道吧，否则面试官可能会追问，问到最后你不知道就给了他不好的印象，索性说不知道也没什么

l 哪怕技术不好，不要不自信，也不要表现出恼怒的情绪，很多时候面试官确实不是刁难你，对谁都是问这些问题，所以表现出这些情绪没什么意义

评论: 55　查看评论　发表评论

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

最近项目的一些心得（纯贴代码）

lovecherry — Sun, 19 Jul 2009 11:56:00 GMT

阅读: 1516 评论: 5 作者: lovecherry 发表于 2009-07-19 19:56 原文链接

唉，眼看着ASP.NET第一步已经出版2年了，这2年貌似自己进步也不是很大，最近完成了一个项目，分享一点代码吧，以后要复制粘贴自己也方便点，因为主要是给自己看的，大家看不懂别见怪。

1、WCF中统一处理异常，并自动包装为 FaultException 返回给客户端：

先建立这么一个ServiceBehavior特性：

    [AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = false)]
    public sealed class ErrorHandlingBehaviorAttribute : Attribute, IServiceBehavior
    {
        #region IServiceBehavior Members

        public void AddBindingParameters(ServiceDescription serviceDescription, System.ServiceModel.ServiceHostBase serviceHostBase, System.Collections.ObjectModel.Collection<ServiceEndpoint> endpoints, System.ServiceModel.Channels.BindingParameterCollection bindingParameters)
        {

        }

        public void ApplyDispatchBehavior(ServiceDescription serviceDescription, System.ServiceModel.ServiceHostBase serviceHostBase)
        {
            IErrorHandler handler = new ErrorHandler();

            foreach (ChannelDispatcher dispatcher in serviceHostBase.ChannelDispatchers)
            {
                dispatcher.ErrorHandlers.Add(handler);
            }
        }

        public void Validate(ServiceDescription serviceDescription, System.ServiceModel.ServiceHostBase serviceHostBase)
        {

        }

        #endregion
    }

然后呢，需要实现啊这么一个自定义的ErrorHandler：

    public class ErrorHandler : IErrorHandler
    {
        #region IErrorHandler Members

        ///

/// Log exception
///

        ///
        ///
        public bool HandleError(Exception error)
        {
            // Ignore communication exception, only log business logic exception
            if (error is CommunicationException)
                return true;

            Log.LogException(error);
            return true;
        }

        ///

/// Warp Exception with FaultException
///

        ///
        ///
        ///
        public void ProvideFault(Exception error, MessageVersion version, ref Message fault)
        {
            FaultException faultException = new FaultException(error.Message);
            MessageFault m = faultException.CreateMessageFault();
            fault = Message.CreateMessage(version, m, faultException.Action);
        }

        #endregion
    }

Log类代码就不写了，爱怎么记录就怎么记录，最后只要把这个特性应用到Service的类上即可。

2、把XML结构转换为span包装的HTML，这样就可以直接为XML的各个层次应用样式啦：

///

/// Convert ab to ab
///

        ///
        ///
        public static string ConvertXmlToHtml(this string xml)
        {
            if (string.IsNullOrEmpty(xml))
                return string.Empty;

            XElement root = XElement.Parse(string.Format("{0}", xml));

            foreach (var el in root.DescendantsAndSelf())
                el.AddAnnotation(
                    new XElement("span",
                        new XElement("ApplyTransforms"),
                        new XAttribute("class", el.Name)
                    )
                );

            XElement newRoot = XForm(root);
            return newRoot.ToString();
        }

XForm的代码如下：

       private static XElement XForm(XElement source)
        {
            if (source.Name == "a") return source;

            if (source.Annotation<XElement>() != null)
            {
                XElement anno = source.Annotation<XElement>();
                return new XElement(anno.Name,
                    anno.Attributes(),
                    anno.Nodes().Select((XNode n) =>
                    {
                        XElement annoEl = n as XElement;
                        if (annoEl != null)
                        {
                            return (object)(source.Nodes().Select((XNode n2) =>
                            {
                                XElement e2 = n2 as XElement;
                                if (e2 == null)
                                    return n2;
                                else
                                    return XForm(e2);
                            }));
                        }
                        else
                            return n;
                    })
                );
            }
            else
            {
                return new XElement(source.Name,
                    source.Attributes(),
                    source.Nodes().Select(n =>
                    {
                        XElement el = n as XElement;
                        if (el == null)
                            return n;
                        else
                            return XForm(el);
                    })
                );
            }
        }

3、LINQ TO XML来更新和删除XML：

///

/// Remove unwanted embedded translation according to culturecode
///

        ///
        ///
        ///
        public static string RemoveTranslationFromNotePanel(string text, string cultureCode)
        {
            var xml = XDocument.Parse(text);
            var translationList = from t in xml.Descendants("trans")
                                  select t;
            if (cultureCode == "cs")
                translationList = translationList.Where(t => t.Attribute("lang").Value == "CN");
            if (cultureCode == "ch")
                translationList = translationList.Where(t => t.Attribute("lang").Value == "CNS");
            translationList.Remove();

            return xml.ToString();
        }

        ///

/// Separate out title in notepanel xml
///

        ///
        ///
        ///
        public static string RemoteTitleFromNotePanelAndGetTitle(string text, ref string title)
        {
            var xml = XDocument.Parse(text);
            var titleElement = (from t in xml.Descendants("title") select t).FirstOrDefault();
            if (titleElement != null)
            {
                title = titleElement.Value;
                titleElement.Remove();
            }
            return xml.ToString();
        }

        ///

/// Handle , and tags
///

        ///
        ///
        public static string FormatSenseDefinition(string text)
        {
            var xml = XDocument.Parse(text);

            // content here -> (= content here)
            var glTag = (from t in xml.Descendants("gl") select t).ToList();
            glTag.ForEach(gl => gl.Value = string.Format("(= {0})", gl.Value));

            // content here -> content here
            var xTag = (from t in xml.Descendants("x") where t.Attribute("refurl") != null select t).ToList();
            for (int i = 0; i < xTag.Count; i++)
            {
                var x = xTag[i];
                int guidewordID = 0;
                if (int.TryParse(x.Attribute("refurl").Value, out guidewordID))
                {
                    if (guidewordID != 0)
                    {
                        var headwordText = ContentHelper.GetHeadwordTextFromGuidewordID(guidewordID);
                        if (!string.IsNullOrEmpty(headwordText))
                        {
                            x.ReplaceAll(new XElement("a", x.Value, new XAttribute("title", headwordText)));
                        }
                    }
                    else
                        x.ReplaceAll(new XElement("a", x.Value, new XAttribute("title", x.Value)));
                }
            }

            // content here -> content here
            var nondvTag = (from t in xml.Descendants("nondv") where t.Attribute("refurl") != null select t).ToList();
            for (int i = 0; i < nondvTag.Count; i++)
            {
                var nondv = nondvTag[i];
                int guidewordID = 0;
                if (int.TryParse(nondv.Attribute("refurl").Value, out guidewordID))
                {
                    if (guidewordID != 0)
                    {
                        var headwordText = ContentHelper.GetHeadwordTextFromGuidewordID(guidewordID);
                        if (!string.IsNullOrEmpty(headwordText))
                        {
                            nondv.ReplaceAll(new XElement("a", nondv.Value, new XAttribute("title", headwordText)));
                        }
                    }
                    else
                        nondv.ReplaceAll(new XElement("a", nondv.Value, new XAttribute("title", nondv.Value)));
                }
            };

            return xml.ToString();
        }

评论: 5　查看评论　发表评论

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

有关CPU占用和缓存的一些见解，希望给大家一些启发

lovecherry — Thu, 07 May 2009 13:12:00 GMT

阅读: 2777 评论: 16 作者: lovecherry 发表于 2009-05-07 21:12 原文链接

首先说说缓存的问题，比如我们有1000000个字符串构成的List需要缓存在内存中，大约占用了100M的内存空间。如果需要对这些数据进行检索的话，很明显直接由于数据量太大，即使在内存中检索效率也不会太高。

一般可以想到的办法就是利用层次话的字典结构来解决，比如SortedList> 这样就构成了2层结构，可以把字符串的第一个和第二个字母作为字典的Key，这样一下子可以把检索的数据量下降2个数量级都不止。

当然，在现实应用中可能存放的不是List而是一个List，这个Entity里面可能有N个属性，我们可能需要检索的就不止是一个字段这么简单了，可能需要为了检索Entity中的ID属性做个Dictionary，也可能需要为了检索其中的Name属性做一个Dictionary>，这就需要多份字典。

前面说过了，这个原始数据List占用100M内存，那么你可能会想了，再来一个SortedList>那么就需要200M内存了，如果多份字典的话，更占内存？但是想想字典结构的效率真是高啊，怎么取舍呢？其实，如果你试验一下的话可以发现，再弄个SortedList> 可能只会占用1M内存，加起来一共是101M而不是200M，这是为什么呢？

记得引用类型和值类型的区别吗，如果你的数据结构大部分是引用类型，比如string的话，一个string的List，它其实存放了N个处于托管堆上的string的指针，那么如果我们再来一个字典结构的话，不是说我们就多存放了这些string，而是多存放了一套指针，外加Key所占用的一些空间。所以，遇到这种情况不用吝啬多一些字典结构来提高效率。

上面的例子我想说明一个问题，缓存多份数据不一定会占用相同的多份内存。

还有，缓存的数据可以放在那里呢？一般来说有这么几种，static变量，.NET类库提供的HttpRuntime.Cache或者就是一些分布式的缓存解决方案，比如memcached。

有一些误解，很多人非常不喜欢static变量，我想有两个原因，一是可能觉得把100M数据存放到一个变量中，这是很可怕的事情，一个变量竟然占用100M内存，其实我们大多时候缓存的是一个引用类型，变量存放的只是一个指针罢了，100M的值类型确实可怕，二是很多做ASP.NET的人会觉得不能乱用static变量，就产生了这个错觉。其实，我觉得static变量的问题在于它没有线程安全的机制，二是它作为缓存方案不能过期，一旦创建后也不能删除，只能把它设置为空引用，等待GC回收。但对于某些情况，静态变量是适合的，比如我们缓存的数据是只读并且永远不需要过期的，静态变量作为缓存的确足够简单，也不用担心“丢失”！

HttpRuntime.Cache之类的方案的优势在于它提供了过期、依赖、线程同步的支持，也是我们用的最多的。

最后说说分布式缓存解决方案，比如memcached。其实我觉得在一般情况下不要去随便使用分布式的缓存方案，除非我们能满足以下的需求：1、缓存的数据非常多，一台机器的内存不够用，确实需要分布。2、需要确保数据不能丢失，在多台机器上做备份。为什么说不要轻易用，因为分布是有代价的，如果应用服务器和缓存服务器分开的话，势必就需要TCP通讯，这是一个消耗，另外一个消耗是缓存的数据需要序列化和反序列化。分布式缓存使用缓存一些直接能绑定到UI的数据，或者说直接用于呈现的数据，对于大块的数据非常不适合存放到memcached中。比如之前提到的List，如果这个数据是100M，它不能直接用需要做一些计算再返回给WEB服务器，那么我们做的事情就是序列化后缓存到memcached中，然后再反序列化从TCP获取，放到内存中计算后返回给WEB服务器，然后内存中的100M数据等待GC回收。其中白白折腾了网络、CPU和内存（虽然会回收，但是GC一直回收100M的数据，谁受得了）。

上面的例子我想说明一个问题，缓存的方案需要根据应用来选择，静态变量不一定不好，分布式缓存也不一定好。

最后，还有一个有关CPU占用的有趣问题，很多人很怕服务器占用CPU很高，觉得CPU占用一高就有性能问题。其实我想说的是，有的时候CPU占用的高不一定是坏事情。假设有两个网站。A网站它的数据源是数据库，每一个请求（假设是同步请求数据库）都需要1秒来从数据库获取数据，由于IO操作的时间会比CPU处理数据时间长很多，所以这个网站即使很繁忙，WEB服务器的CPU占用还不是很高，用户一个页面打开至少要等1秒，网站管理员看着WEB服务器CPU常年处理20%的情况觉得很满意，但想想这真能说明网站性能高吗？还有一个网站B，它数据都是从内存中读取的，由于内存的操作会比IO操作快很多，CPU处理一个请求的数据只需要20毫秒，由于网站页面速度快，用户满意度和数量比A网站高很多，CPU很忙，常年处于90%的负荷，网站管理员看了觉得很害怕，是不是哪里出现性能问题了，服务器会不会瘫痪。其实，我觉得B网站的管理员应该高兴，因为B网站的用户比A网站高一个数量级，服务器虽然很忙，但页面打开速度很快，CPU得到了充分的利用。

上面的例子我想说明一个问题，只要不是死循环等恶性代码问题的话，CPU如果占用的高不一定就是坏事情。

很多时候事情往往不是像我们想的那样，很多时候好的东西往往也不一定是适合的。希望这三个小例子能给大家一些启发。

最后，想说一下最近使用LINQ的经验。不可否认，如果不分层，在网站中直接使用LINQ TO SQL和LINQ进行数据的存取以及转换，结合匿名类型等特性，至少提高开发效率一倍。有很多人关心LINQ的效率，其实我们应该要区分LINQ还是LINQ TO SQL，是使用LINQ TO SQL进行数据的转换还是使用LINQ进行内存中数据的转换很关键。要知道，尽量从数据库中拿少点东西，尽量少的进行数据库访问，所以说LINQ TO SQL的代码不适合放在循环中，如果要对大量数据操作的话，要先ToList()加载到内存中，然后之后的工作就是LINQ(TO OBJECT)了。如果项目对性能要求高的话，尽量在做好项目之后，多看看SQL监视器，观察一下页面究竟访问了几次数据库，因为程序写的很爽的时候可能会迷糊，导致页面访问N次数据库，这个时候要使用LoadWith来“化解”。

评论: 16　查看评论　发表评论

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

没有linq让我怎么活

lovecherry — Fri, 06 Mar 2009 04:34:00 GMT

阅读: 2331 评论: 10 作者: lovecherry 发表于 2009-03-06 12:34 原文链接

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Xml.Linq;
using System.IO;

public partial class Default8 : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        var data = new List<WordComponents>();
        (new DirectoryInfo(Server.MapPath("data"))).GetFiles("*.xml").ToList().ForEach(file =>
            {
                XDocument doc = XDocument.Load(file.FullName);
                var q = from w in doc.Descendants("entry")
                        select new WordComponents
                        {
                            Word = w.Descendants("hw").FirstOrDefault().Value.Replace("_", "").Replace("^", ""),
                            idioms = (from i in w.Descendants("idiom")
                                      select i.Element("phrase").Value).ToList(),
                            phrases = (from p in w.Descendants("phraserec")
                                       select p.Element("phrase").Value).ToList() ,
                            phrasalverbs = (from pv in w.Descendants("phrasal_verb")
                                            select pv.Element("phrase").Value).ToList(),
                        };
                data.AddRange(q.ToList());
            }
        );

        var qu = from w in data orderby w.runons.Count + w.phrases.Count + w.phrasalverbs.Count descending select w;
        qu.Take(500).ToList().ForEach(w => Response.Write(string.Format("{0} contains {4} elements (idiom count:{1}/phrase count:{2}/phrasal verb count:{3})
", w.Word, w.idioms.Count, w.phrases.Count, w.phrasalverbs.Count, w.idioms.Count+ w.phrases.Count+ w.phrasalverbs.Count)));
    }

    public class WordComponents
    {
        public string Word { get; set; }
        public List<string> runons { get; set; }
        public List<string> idioms { get; set; }
        public List<string> phrases { get; set; }
        public List<string> phrasalverbs { get; set; }

        public WordComponents()
        {
            runons = new List<string>();
            idioms = new List<string>();
            phrases = new List<string>();
            phrasalverbs = new List<string>();
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Xml.Linq;
using System.IO;
using System.Data;

public partial class Default7 : System.Web.UI.Page
{
    public class stat
    {
        public string Name { get; set; }
        public string Value { get; set; }
    }

    protected void Page_Load(object sender, EventArgs e)
    {
        var data = new List<stat>();
        (new DirectoryInfo(Server.MapPath("data"))).GetFiles("*.xml").ToList().ForEach(file =>
            {
                XDocument doc = XDocument.Load(file.FullName);
                data.AddRange((from w in doc.Descendants("entry").Descendants()
                               where w.Attribute("url") != null
                               select new stat
                                  {
                                      Value = w.Attribute("url").Value,
                                      Name = w.Name.LocalName
                                  }).ToList());
            });

        (from d in data
         group d by d.Name into g
        select new { g.Key, Num = g.Count() }).ToList().ForEach(
         a => Response.WriteLine(string.Format("{0}:{1}", a.Key, a.Num)));

    }
}

public static class ext
{
    public static void WriteLine(this HttpResponse response, object o)
    {
        response.Write(o.ToString() + "
");
    }
}

评论: 10　查看评论　发表评论

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

ADO.NET EF不方便之处（BUG）收集帖

lovecherry — Thu, 15 Jan 2009 07:49:00 GMT

阅读: 3398 评论: 23 作者: lovecherry 发表于 2009-01-15 15:49 原文链接

考虑在项目中使用ADO.NET EF，但是怎么都用不顺手，甚至比L2S少了很多关键功能。

我先列几个让我很郁闷的（只用了不到5小时就遇到这么多问题）：

1）存储过程自动封装是一个很常用的功能，在ADO.NET EF中可以和L2S一样对基本的INSERT/UPDATE/DELETE映射存储过程。

也可以对存储过程自动封装，把返回值是结果集的存储过程和实体进行关联，但是很吃惊的是：

a) 设计器并没有提供对返回值不是实体（比如无返回值和标量返回值）的存储过程的自动生成，http://blogs.msdn.com/adonet/archive/2008/12/02/migrating-from-linq-to-sql-to-the-entity-framework-stored-procedures-for-data-retrieval.aspx 一文中一段

The LINQ to SQL Designer allows you to map stored procedures that return scalars. While the Entity Framework does have mapping support to specify stored procedures and functions that return scalars, automatic code-generation of methods that will allow you to use the mapping is currently missing. However, this is something that is being strongly considered for the next release of Entity Framework.

b) 并不支持自定义实体的自动生成：

The Entity Framework does not automatically create return types whilst mapping stored procedures into functions.

It is possible to create the types by hand and to write additional code to execute the stored procedure and materialize the results.

2）设计器不支持从领域模型直接生成数据库结构

3） UPDATE MODEL FROM DATABASE这个功能特别不方便，有的时候会重复生成关系

4）没有提供LOG功能

来看看老外的2个文章：

http://reddnet.net/code/ado-net-entity-framework-impressive-powerful-useless/

The new Microsoft Entity Framework is the latest in a long line of very impressive, yet tragic failures in Microsoft's data access strategy...

这个开场白很寒，文中提到了延迟加载的问题，这位兄弟还是相当激动的。

http://www.kindblad.com/2009/01/11/why-you-should-not-use-the-adonet-entity-framework/

此文中也提到了我说的存储过程和更新模型的问题。

http://blogs.msdn.com/timmall/archive/2008/06/24/vote-of-no-confidence.aspx

此文是官方对社区反馈的一些解释。据说会在将来版本中改进下列方面：

1）自定义POCO->EDM

2） EDM->关系型DB

3）隐式延迟加载

4）持久化透明

请大家补充，我都在想是不是放弃ADO.NET EF而使用SUBSONIC/L2S/NHIBERNATE等了。。。我的想法是不管是什么框架还是工具，易用性是第一的，让我们期待ADO.NET EF1.1/2.0！传说微软的东西不到2.0/3.0别去用？

评论: 23　查看评论　发表评论

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

2005-2008年度个人总结和写书计划？

lovecherry — Tue, 30 Dec 2008 09:38:00 GMT

阅读: 5878 评论: 31 作者: lovecherry 发表于 2008-12-30 17:38 原文链接

以前没写过类似的总结，正巧闲着，流水帐记一下吧。第一次使用live writer发文章，此文发首页4小时:)

01-05读的大学，在大学的时候自学了ASP、网页开发什么的。当时觉得发布一个个人网站到免费空间很有成就感。

当时学ASP是因为某人说ASP很难，你别学了，学不会的。我一开始自学也觉得挺难，后来觉得也就这么几个对象啊。

总结出只要学会request/response/session/cookie/访问数据库就差不多了，后来写了一个什么《十天学会asp》，很多人说好，也有很多人骂。

现在回头看看当时写的什么《十天学会asp/php/asp.net》这样的文章好傻好天真，很肤浅。

后来和学长一起接外包的小活干，装模作样开个小公司，大学毕业了，大家各奔东西，所谓的公司也就散伙。

毕业后找工作，运气不错进入育碧做.NET开发，公司不错，后来经理说录用我是因为觉得我技术不差而且便宜，我寒一个。

育碧其实做的项目都很小，空闲时间也很多，就上上csdn，没想到几个月就混到了4个星星，当时接触.NET才1年不到啊。

拿到4个星星不久就评上斑竹，第一次MVP也就这么来了。06年之后基本就不去csdn了，因为觉得那里很多问题都很初级。

05年混csdn热情还是比较大的，觉得像打游戏升级一样，很有成就感，后来csdn blog太慢就来到了博客园。

育碧后来不做网络游戏了，跟老大来到新的一个网络游戏公司，组建一个开发团队，毕业2年就做管理了。

小公司确实学到很多东西，虽然编码不多，但学到了管理方面一些技巧，也接触到了服务器，很有成就感。

网游行业竞争激烈，08年产品不怎么好了，人气也没了，就琢磨着换个公司，想学学正宗的开发流程。

毕竟以前的一些管理都是自己琢磨出来的，面试了几个公司来到ef，没想到ef的管理也是这么乱。

在围城里面的人总是觉得里面怎么不好，学不到东西，其实很多时候出去了才知道，别人也这样。

07年公司挺忙的，写了一本书，说实话半年又要上班又要写书，日子不好过，而且交稿后出版社又拖了半年才出版。

很多人说写的不错，自己觉得思路应该还是流程的，但是由于写的时候时间实在不够，所以小问题很多。

很多人发邮件问我怎么学习.NET，以前觉得可以速成，现在想想还真不行，东西实在太多，没2年积累不可能，除非是神童。

就学习来说我觉得要想靠公司靠项目学到东西没什么意义，还是要靠自己的学习热情。

而且我越来越体会到，如果先学习应用的东西再慢慢研究到基础的话入门是快，但是提高很慢，基础太重要了，否则以后加速度会很慢，而且容易达到瓶颈后上升不了。02年-04年我研究做网页，05年我研究asp.net的一些基本，06年发掘c#和clr很重要，07年之后基本就在积累架构方面的东西了。很多人说怎么学了几年就这么牛，说实话我觉得就我现在掌握的这些东西让我再培训别人的话2年足够了，我其中很多时间都是浪费的。写书虽然辛苦，但是收益也是很大的，因为平时很多知道只是知道怎么用并不知道原理，要写书你必须知道的更多才能解释清楚。

我脑子里总有一个想法，就是自己学习的过程中其实瓶颈挺多的，懂了之后觉得也就这么回事情。很想把这些东西分享出来，告诉大家其实这不难。有一种冲动在09年再写一本书，写一本提高的书，因为针对初学的书太多了，买什么书都可以入门，但是相对提高的书市面上几乎没有。c#高级编程、 asp.net高级编程在我看来只是覆盖面比较广，里面介绍的东西真的是点到为止，一点没扩展。怎么做其实大家都知道，大家不知道的是为什么这么做，以及如何去扩展。asp.net这个框架其实扩展点很多的（也是面向对象的特点），但是很多人都不知道如何去扩展。想写一本书写asp.net的扩展点，c#中一些所谓的高级特性，以及架构方面的一些心得，asp.net第二步？出版社一般不喜欢这样的书，受众读者太少，而且知识点太分散。这真的很难，就像歌手出专辑，可能其中很多是商业的，不是自己喜欢的歌曲。。。。。

自己初步的考虑：

全书650页左右，特点：

l 写这本书目的是什么？太多入门书只介绍当前领域的基础，.NET初学者要打好基础难道要看N本书吗？而且大多数工作经验丰富的人基础并不好。

l 这本书定位是什么？初学者、认为基础不扎实的.NET程序员、需要面试的人、感觉学.NET遇到瓶颈的人，知道怎么做不知道为什么的人。

l 这本书的特点是什么？遵循ASP.NET第一步风格，还是那句话，没一句抄MSDN，MSDN里面的东西初学者理解不了，我说的都是我的理解。这本书是一个基础+我架构经验的集合，不敢说超越什么，但可以保证你有收获。

l 不会过多介绍具体的技术和实现，主要内容放在基础以及探索上。API变化总是这么快，只有掌握基本的东西才能有快速的学习能力，因此本来考虑要详细介绍的WCF、MVC框架、AJAX框架都不会详细介绍。

下面是初步目录，在写的过程中想到什么就会加入，看到这些我想很多人都会觉得其实自己的知识点空缺还是很多的：

1 WEB服务器、IIS与开发工具（大约30页）

1.1 基础——网页本质

1.2 基础——WEB服务器

1.3 基础——HTTP协议

1.4 基础——SSL

1.5 基础——IIS 6.0

1.6 基础——IIS 7.0

1.7 基础——VS2005

1.8 基础——VS2008

1.9 基础——技巧和快捷键

1.10 配置和扩展——项目文件和解决方案文件

1.11 配置和扩展——项模板和项目模板

2 .NET Framework（大约50页）

2.1 版本和基本概念

2.2 编译

2.3 垃圾收集

2.4 安全模型

2.5 异常管理

2.6 应用程序域

3 C#与类库（大约150页）

3.1 不可变类型

3.2 修饰符

3.3 值类型引用类型

3.4 浅拷贝深拷贝

3.5 参数传递

3.6 转换

3.7 委托和事件

3.8 泛型

3.9 反射

3.10 异步操作

3.11 匿名方法

3.12 Lambda表达式

3.13 LINQ语法

3.14 多线程

3.15 哈希和加密

3.16 序列化

3.17 CodeDom

4 WEB开发（大约50页）

4.1 基础——Javascript

4.2 基础——XHTML

4.3 基础——XML/XSL

4.4 基础——AJAX

4.5 基础——CSS

4.6 基础——浏览器兼容

5 ASP.NET（大约150页）

5.1 基础——Module

5.2 基础——Handler

5.3 基础——请求生命周期

5.4 基础——页面生命周期

5.5 基础——Cookie

5.6 基础——Session

5.7 基础——ViewState

5.8 基础——异步页

5.9 配置和扩展——身份验证和模拟

5.10 配置和扩展——授权和角色管理

5.11 配置和扩展——控件适配

5.12 配置和扩展——缓存

5.13 配置和扩展——错误处理

5.14 配置和扩展——健康检查

5.15 配置和扩展——进程模型

5.16 配置和扩展——编译部署

5.17 配置和扩展——Trace

5.18 配置和扩展——全球化设置

5.19 综合实例——URL重写

5.20 综合实例——静态页面

5.21 综合实例——SSO

6 数据访问（大约100页）

6.1 数据库引擎

6.2 SQL Server 2008——存储结构

6.3 SQL Server 2008——内存管理

6.4 SQL Server 2008——预编译

6.5 SQL Server 2008——事务和隔离

6.6 SQL Server 2008——并发和死锁

6.7 SQL Server 2008——索引

6.8 SQL Server 2008——锁定

6.9 SQL Server 2008——增强TSQL

6.10 SQL Server 2008——XML

6.11 SQL Server 2008——新功能

6.12 ADO.NET——连接和连接池

6.13 ADO.NET——在线模式离线模式

6.14 LINQ TO SQL简介

6.15 LINQ TO XML简介

6.16 LINQ TO DataSet简介

6.17 ADO.NET EF简介

7 设计和架构（大约50页）

7.1 设计模式

7.2 MVC以及框架

7.3 AOP以及框架

7.4 IOC以及框架

7.5 SOA以及框架

7.6 负载均衡

7.7 分层

7.8 安全

8 我的架构实战（大约50页）

8.1 硬件架构

8.2 基础架构

8.3 软件架构

8.4 流程管理

评论: 31　查看评论　发表评论

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

SOA概念误解实施要点

lovecherry — Sat, 06 Dec 2008 09:24:00 GMT

阅读: 1209 评论: 3 作者: lovecherry 发表于 2008-12-06 17:24 原文链接

SOA实施要点：

1、 SOA的构建次序。是从上到下还是从下到上？我个人倾向于从大局进行把握，因为SOA中重要的不是技术，而是对业务的定位。如果从下往上去设计服务的话可能会做很多重复劳动工作，或者在真正去用的时候返工。应该在设计的时候进行足够的需求调研，挖掘出业务的核心并对外提供。但是设计时候肯定会有很多没考虑到的东西，或者说想的过于粗，那么在开发的时候也可以进一步去讨论需要公开的服务，补充上粒度比较细的那一部分。也就是说先把握大局从上到下，然后抓住细节从下到上。

2、 SOA的测试过程。作为客户端程序，在需要的服务尚未建立的时候，需要自己创建基于接口的FAKE服务进行测试，等服务在网络端点上部署之后使用服务代理进行替换（当然，理想的方式是由客户端代理自动生成FAKE服务和测试数据）。作为服务的主办者，需要在服务发布之前对服务的边界、逻辑和性能进行严格的测试，作为服务端是不知道我的客户是什么的，我要处理所有可能的情况。

3、 SOA的持续建设。虽然说契约是不变的，但不代表服务不变。服务的业务逻辑是需要不断完善的。服务也是可以扩充的。没有什么事情是在一开始的时候就完美的，如果服务没有持续建设作为保障的话，可能花费很大时间做出来的服务并没有多少人愿意来使用，导致整个服务层越来越孤立越来越偏离SOA，最终导致SOA实施的失败。我们不要去怕服务做的不好，不好的地方就去不断修正，如果服务没有客户来消费的话那就很危险了。

4、 SOA的基础结构。不管是叫ESB或者其他什么名词，基础结构总是需要的，而且应该在实施前进行这个基础结构的建设。其中有一些东西是非常重要的。一是可靠性的保证服务，比如如何去做服务的负载均衡，如何去做事务，如何去做服务的流量控制，如何实现消息的加密和安全。第二是服务的监控和管理，比如服务调用的异常记录，系统的状态，系统的配置，系统的部署。第三是服务的中介，比如服务的路由、异步队列、消息转换。第四点是服务的管理平台的平台，比如流程管理、契约管理、部署管理。从技术上说这个基础结构应该是尽量对开发人员透明的，并且也是也是需要不多的人为的参与，以代码生成工具、AOP、管理工具等方式实现。这一套框架是SOA开发前期需要完成的，也是技术难度最大的。在完成后对开发人员进行技术上的培训和流程上的培训。

SOA概念误解：

1、 SOA 不是技术（当然也不是WEB服务）、不是产品、不是新概念、不是一尘不变的。SOA是SO的A，也就是说是符合面向服务思想的架构（可能需要WEB服务作为某项技术来参与，但不能说它就是WEB服务）。SOA的成功需要一套产品的支持，但本身不是产品。SOA为什么不是新概念？我们生活中需要用到各种服务，我们只需要按照要求，写一些表格（契约），对方就会给我们结果，这不是SOA是什么，计算机硬件中很多地方也是SOA的思想（其实我一直觉得软件工程走在硬件工程的后面，很多开发上的思想在硬件设计中都能找到原型）。SOA没有实施结束的那一天，一定是不断变化不断改进的。

2、 SOA可大可小，可以是企业内部的，也可以是企业与企业间的，可以是同构平台也可以是异构平台，因此，SOA很难套用，甚至没有哪个公司对SOA的实施是一模一样的。SOA可能会很简单也可能会很复杂，复杂不是说技术上的复杂，很多时候在于管理上的复杂性，因为里面融合了业务，业务是会变化的。复杂性还体现在可能是基于老系统进行实施，需要考虑到数据兼容问题以及数据集中的问题。

3、 SOA不一定是一层的。没有规定服务的消费者一定是客户端，服务的消费者可以是服务，也就是服务的组合，多层的服务能进一步提高重用。

评论: 3　查看评论　发表评论

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

我对SOA的认识以及心得

lovecherry — Tue, 02 Dec 2008 23:31:00 GMT

阅读: 4055 评论: 23 作者: lovecherry 发表于 2008-12-03 07:31 原文链接

注：本文来源于我给公司内部发的邮件中，所以背景都是基于我们现在的应用，而且思路也很混乱，请大家见谅。

自05年开始接触到分布式架构，06年在原先的基础上从头开始设计了一套分布式架构，当时SOA这个概念也没这么火。整个大平台的开发、性能和可扩展性都得到了考验，觉得有一些东西想和大家一起分享。

我不知道我所说的这些算不算真正的SOA，我也没读过什么SOA的书籍，我觉得SOA这个概念非常抽象，任何概念的产生都是由原因的。因此，我也不会说一些抽象的原则，只是想说一些在过去几年实施“SOA”过程中的一些心得和一些细节，希望对大家有用。

不说什么是SOA，先来说说我们现有架构遇到的一些问题：

l 同样一个逻辑，A系统（ASP）使用COM实现一份（我们现在的JAVA库），B系统（.NET）在开发的时候觉得调用JAVA也是很麻烦的，索性自己实现一份逻辑，可能是存储过程，也可能是在代码中硬编码SQL，C系统（由系统部门开发的.NET程序）也用到了相同的逻辑，由于和产品部门缺乏必要的沟通，也实现了一份逻辑。最后，如果这个相同的逻辑需要修改，则需要修改A、B、C三个系统，一份逻辑在三个地方实施有几个缺点，一来是因为如果需要修改要改三个地方，二来是增加了工作量，三来是占用了不必要的资源（因为大家可能都实现了自己的缓存）。

l 所有网站全部部署在一个WEB服务器上，直接实现负载均衡。这样的方案有几个缺点，一是几乎没一个网站程序都有自己的缓存，每台服务器的缓存是冗余的，而且甚至每个网站中的缓存都有重复，二是如果一个网站有问题会影响到其它网站（比如进程回收，应用程序池不能100%解决这个问题，而且我们现在并没有注重应用程序池的划分，又比如某些应用是长请求、过长时间占用线程），三是不能有效利用服务器资源，这是因为不是每一个网站都具有相同的访问量，不是每一个网站都需要相同的资源（有些需要特别多IO、有些需要特别多CPU、有些甚至是内存）。

虽然说我们现在是使用了三层架构，但并没有什么重用，而且所有的层还是部署在相同的服务器上的。为了解决前面的2大问题，我们首先想到了：

l 是不是有什么方法可以让相同的逻辑被其它系统重用？

l 是不是考虑把逻辑以服务的形式对外部（其他模块）公开？

由此引入面向服务架构的概念，我们通过这些公开的服务进行逻辑的重用，提高系统性能也降低了模块之间的耦合性。架构图见我以前写的文章http://www.cnblogs.com/lovecherry/archive/2008/06/18/1224496.html

如果确实采用这种架构，我们的开发方式会有什么改变呢？

l 在一般情况下，我们一般认为A系统对应A数据库，B系统对应B数据库，每一个系统都有自己的数据库。传统的方式是A系统和B系统在数据库端直接使用JOIN进行交叉耦合。如果实施SOA的话，最佳实践应该是对于大多数系统来说，禁止A系统直接访问B系统的数据库，反之亦然。我要你的数据，就必须调用你公开的服务。而且这个服务或者说接口或者说契约，尽量是粗粒度的。比如一个逻辑包括X和Y和Z三个过程，如果独立提供三个方法的话，每一次方法调用都是网络调用的过程，性能比较低，而且更重要的原因，这个模块提供了这么细粒度的三个方法，如果这三个构成了一定逻辑的话，很有可能这个逻辑就在调用方和提供方两个模块都实现了相同的逻辑。虽然说确实是提供了服务，但是没有达到封装逻辑这个重要的目的，而且也产生了性能的下降，这种服务就显得很不值得。

l 一个大系统有许多模块或者说子系统，每一个都有自己的复杂逻辑和存储结构。开发人员可能只熟悉自己的那一部分，如果我的系统确实要用到其它系统的数据，按道理是应该想到调用它提供的程序集。很多时候我们并没有这么做，是因为我们并不知道对方有没有提供我需要的功能，即使知道提供了也不知道怎么去使用，如果要去用的话可能熟悉对方系统的时间会比直接在数据库中进行JOIN需要的时间还要长。这是一种恶性循环，因为这样又导致了一个逻辑在多处出现，一份数据在多处取得、保存和缓存。有了SOA，我们应该能在SHAREPOINT或WIKI上看到一份清单，在哪个HTTP或TCP端点上具有什么服务，服务中有哪些方法，这些方法是干什么的，返回什么，传入什么，使用的注意事项，如果我开发的系统需要用到外部的数据，我第一时间想到的不应该是去看数据库中我需要的数据在哪里，而是应该是去看看是否对方系统提供了这样的服务，如果没有提供的话则和服务的提供者进行一些沟通。你可能会问，我作为系统的开发者，我也不知道要对外提供哪些服务，我也不知道别人需要用到什么，确实是，但是至少我们现在可以做的是把内部使用到的一些逻辑以服务形式对外公开，一般来说自己系统的这些函数如果能满足自己要求的话从功能上来说可以满足别人要求，只不过别人可能需要的并不是这么多罢了。

l 我们现在做TECH SPEC的时候可能关注内部的实现，如果是SOA的话，我们就需要关注现在在做的这个系统会用到别人的哪些接口，别人可能会用到我什么接口，我需要公开出来。可能还会考虑，我用了ABC三个系统的接口，是否需要把这个逻辑以粗粒度服务公开出来。每一个公开接口的参数、返回都需要仔细考虑，把这些都列入到架构设计中，和架构师一起完成服务的定义。开发人员可能只对自己系统的接口和逻辑比较熟悉，架构师的作用是给开发人员建议，哪些接口你可能需要，哪些接口你可能需要对外提供，是否需要做缓存。

l 我们现在的部署是非常简单的，如果实施了SOA，很有可能一个系统需要调用十几个外部子系统的接口，每一个接口都需要制定地址、调用策略以及契约。地址和调用策略需要是可配置的，一般定义在配置文件中或者数据库中，这样一个系统的部署可能非常复杂，打个比方就像芯片的引脚一样，有很多，一个引脚没有接到合适的地方，系统就不能工作。虽然部署负责了，但是系统之间的耦合非常小的，大家只是依赖于某个网络环境中的地址，依赖于某个契约。这样的话，系统的伸缩性就很强，有些服务需要很高的资源，就给独立的服务器，有些服务占用资源很小，可以合并在一起。当然，也可以根据服务的性质，比如特别需要IO、特别需要CPU来分配到合适的服务器上。服务器并不一定是一样的，有的服务器内存特别大，有的服务器CPU特别好。

l 还会遇到一个问题，就是开发人员不太愿意调用其它的接口。一是对别人的东西往往默认会觉得是实现糟糕的，性能很差的，二是觉得不放心，会不会到时候你没给我正确的数据，影响我的开发，产生相互推卸责任的问题。其实，这种想法不对，一个人不可能开发系统的全部，作为使用者来说要使用别人的接口信任别人的接口，作为接口提供者来说需要积极对自己的接口负责，进行完善的单元测试，如果调用者有特别的需求在讨论后进行改进。这也就是说引入SOA的话，我们需要更多的沟通。

说的有点乱，接下来想说说我在实施过程中遇到的一些细节问题，很多时候SOA实施的失败都是因为一些细节。

l SOA的接口设计必须基于业务的。架构师应该是一个总导演，对所有系统的业务都有一个认识，理解业务之间的关系，和开发人员一起定义合理的接口。这包括，接口是否代表了业务、是否是合适的粒度、是否会有性能问题，别小看接口设计，一旦确定以后很难修改，接口的好坏决定成败，我列为第一要素。

l 在实施中，管理很关键，有许多要点是需要有强制的。比如除非特殊需要不能直接引用其它数据库，即使是本系统也应该引用本系统的服务，也就是说网站项目里面没有连接字符串、没有数据访问逻辑，只有端点的配置。还比如是A系统的开发人员有这个责任为A系统对外的所有接口进行后续的维护和功能扩展，不是说A系统结束了，我的数据我也不管，不行，别人如果需要的数据确实是我的数据的话，我就要管。

l 从性能角度考虑，一般内网中的服务通讯采用TCP（二进制序列化），公网的走HTTP。还有一种方式是IPC方式，进程间通讯，我们以前也用的挺多的，虽然说缓存应该在一个地方建立。但很多时候，某个方法的调用是每次访问页面都需要进行一次或多次的，如果再进行网络调用的话性能很成问题，比如论坛上的脏话过滤，如果某个脏话服务提供了脏话过滤的接口，如果这个这个接口需要TCP调用的话性能不高，这个时候我们会考虑把这个服务部署在WEB服务器上，而不是APP服务器上，IPC方式进行进程间通讯。

l 到最后我们会发现我们有20个子系统，也就至少有20个服务（一般是以Windows服务部署在APP服务器上）。而且如果服务部署多份做负载均衡的话，可能就有上百个网络地址。一个网站如果引用了5个服务，就需要一个一个IP地址（或者说端点）进行配置，如果将来服务迁移，那么这些网站的配置文件修改是一个大问题。虽然说我们会有一个拓扑图来描述网站之间服务的依赖情况，但是配置文件的修改工作量不小而且容易出错。推荐的做法是有一个数据库来存放所有服务的端点定义、描述，使用一个单独的服务来提供所有服务的端点信息，在网站中只需要配置这个服务的端点信息，然后引用各种服务的契约就可以了。考虑到效率关系，在每一个WEB服务器上都安装有这个配置服务，以IPC方式提供所有网站进行调用，当然，其中的端点信息都会做缓存。

l 前面说的是网站引用服务的端点信息配置问题，还有一个问题就是服务的健康监视问题，服务是以Windows服务形式运行的，我们需要检测Windows服务的状态，占用的CPU和内存信息。我们在每一个APP服务器上又装有一个AGENT服务，专门用于监视这些服务进程的情况，一旦发现问题会第一时间通知网络部门甚至是开发人员，当然服务无响应的情况比较少，一般常见的情况是服务没有正确部署（缺少DLL不能启动），或者是占用了过多的内存。这个AGENT的另外一个作用就是收集服务器上的错误日志，并且负责更新和重启服务。也就是说所有服务的更新是自动化的更新，我们发布的时候发布到指定的RELEASE服务器，由专门的管理工具进行服务的自动更新，服务如果做负载均衡的话手动更新很麻烦。而且很多情况下相同的服务需要在多个服务器部署，比如IPC服务。

l 服务的实例管理问题，一般有SINGLETON和SINGLECALL等方式。推荐采用SINGLECALL方式，如果服务具有状态的话会大大增加服务的开发难度，一是需要考虑线程同步问题，二是需要考虑生命周期。其实，我一直觉得有状态的服务配合ORM数据访问层的使用是很好的，但做起来可能会遇到很多问题。

l 在存储过程中做事务还是很简单的，SOA如果要做分布式事务的话，实现不是打大问题，但性能是很大的问题，很容易引起数据库对象的死锁。大多数情况下我们对分布式事务的替代方式是采用队列，放到队列中的东西就认为是一定可以成功的，对于不使用队列的情况，如果调用失败了则记录日志，不会进行回滚。除非涉及到钱的地方才做分布式事务。

l 版本问题也是需要考虑的。传统的实现方式是，如果新增接口的话以前的程序是没有影响的，如果万不得已需要修改接口的话就大吼一声，我这个接口要改了，然后给大家发一份，请调用者按照我的要求修改一下，连同我的服务一起重新发布。对于WCF的话，有MEX元数据交换，这样就不用手动引用新的契约，只需要从HTTP地址上更新新的服务即可。但有一个不得不考虑的问题就是万一在调用其它服务的时候发生错误了，我们怎么知道是哪个服务的版本出现问题了呢。我们是这样做的，调用服务的代理有一层封装，如果网络调用发生错误的话，会记录详细的错误信息，哪个服务（服务的版本）、哪个方法在哪个端点上的调用、传入的参数是什么，返回的是什么。这样，在部署的过程中发生错误或是版本问题，我们就很容易知道错误的原因了。那么怎么知道服务的版本呢？没一个服务都约定有一个GetVersion方法，这个方法两个作用，一是给管理工具测试这个服务是不是还有效，二是给配置服务获取服务的版本号。

l 如果引入SOA的话，不可避免的是大大增加了整个系统的部署复杂性。想一下，在LIVE上，我们可能有20个WEB服务器，10个APP服务器（我们以前是2：1这样进行配置的，服务按照类型和资源不同放在不同的APP服务器，WEB服务器CPU特别强，APP服务器是廉价服务器，有足够大的内存，对于WEB程序来说确实没什么大的CPU计算，服务也就是缓存比较厉害）。10个APP服务器上放100个服务，就产生了100个端点地址。开发人员其实不用考虑服务在LIVE上怎么部署的，需要架构师在部署的时候协调部署团队一起完成部署工作，架构师知道哪个服务部署在哪个服务器最合理，以哪种信道进行部署最合适。部署团队需要对各个服务器的结构很清楚，也要学会使用健康监控工具（我前面提到的监控服务运行状态的工具和异常管理工具来发现部署上的问题），这就对部署团队的要求更高了。实在不行的话可以要求开发人员参与，开发人员应该没权限直接进行服务的部署，但是有权使用两个工具的，一来用于排查问题，二来也会有很大的成就感。

l 服务监控工具以一个拓扑图形式展现整个网络上WEB服务器、APP服务器的IP地址、CPU内存使用，以及服务的引用情况和每一个服务对CPU和内存的占用，以及服务的健康情况。监控人员24小时值班负责监控，出问题的时候及时重新启动相关服务。异常管理工具每天收集各个系统的异常，开发人员每天上班和下班的时候查看一次这个工具，知道自己负责的模块产生了哪个异常（异常有几种，一种是程序有BUG，一种是外部有人在攻击造成的，还有一种是前面说的服务的版本和运行问题产生的异常）。当然，架构师也应该时刻关注这2个工具，知道整个系统的健康情况。

l 从网络上来说，APP服务器应该跨2个网段，DB服务器应该外部不能直接访问，所有数据库操作都是通过APP服务器提供的服务访问DB的，网站不具有任何连接字符串不能直接访问DB服务器（不在同一网段）。WEB服务器和APP服务器之间应该走TCP，如果是跨国的话应该有VPN链路。

l 从软件架构上来说，我们以前使用的是.NET Remoting对内，Web服务对外的方式，中间层以Windows服务作为载体。对于.NET 3.5时代，可以采用WCF+Windows服务承载的方式。WCF支持元数据交换是一个优点，另一个优点是方便TCP/HTTP各种绑定的切换，当然也可以同时提供多份绑定。如果是细粒度服务的话，可以使用ADO.NET DATA SERVICE+ADO.NET EF的方式直接进行提供。表现层可以直接使用ADO.NET DATA SERVICE也可以使用自定义的JSON/XML数据，不属于SOA的范畴就不扩展了。

总结一下：

l 对于ETOWN的应用，SOA架构是绝对适合的。

l 实施SOA，技术不是问题，最大的问题还是管理和沟通（协作）。

l 实施SOA的话，我们需要重新构建一套基础架构，提供统一的端点配置管理、异常管理、健康监控、契约协作平台等。不然到最后的配置和管理将会很混乱。

l 我们不需要更多的服务器，但我们需要更合理的分配服务器。而且整个系统的部署架构可能随着时间的迁移不断调整的，合并压力小的服务，拆散压力大的服务。怎么做负载均衡，这都是一直调整的。

l 实施SOA需要开发人员有更好的意识，包括协作意识，包括架构意识。当然，也需要架构师能够参与到每个项目中去，心中对业务有大局观。

l 配置可能是复杂的，需要有工具来确保这个复杂的过程。服务和网站怎么配置是很重要的事情，需要架构师和开发人员讨论决定，不是说随便放上去能用就可以。

l 在做架构的时候要站在较高的角度来看，眼光要长远，暂时的性能问题不一定是问题。按照网络/磁盘/内存/CPU的层次来考虑。很多时候SOA和性能是有冲突的，就像不能一味觉得ORM性能不好就不去使用。考虑80/20原则，任何东西满足了80的应用就达到了目的，剩下的20进行特殊处理。

补充几点：

l 从服务契约设计上来说，应该让这个契约尽可能独立，不依赖于其它的契约。服务的调用过程不能依赖于服务本身的状态，应该在任何情况下服务的作用不会由环境所变。

l 虽然说是内部实施，但最好数据契约的类型是标准类型，通用类型，原生类型，方便以后做开放API的时候真正实现对外的服务。其实SOA强调松耦合性，因异构平台协作的需求产生，强调一切基于消息，无关服务平台。

l SOA的实现包括业务分析、契约规划、服务管理、消费者管理、文档管理、配置管理、迭代整合等重要步骤，不是说我要建立A契约就建立，我要消费A契约就消费，要体现在管理中。我一直觉得SOA不是组件升级到服务这么简单，软件开发流程、管理流程、设计分析方法、配置管理都会有巨大的改变，前期准备要充分。

l 在建立前期需要制作完成一个基础的架构供开发人员使用。比如说是不是需要扩展VS内建的WEB引用，使得生成的客户端代理包括异常处理、端点配置（从配置服务中获取）等内容。非业务相关异常的收集和发送等工作应该是自动的，无需编码。由于调用的复杂性，服务可能还会调用服务，在部署的时候配置问题很难察觉，所以其中的异常处理非常重要。

l 项目完成后的代码审阅需要对项目中用到的服务进行逐一检查，如果有改变需要在拓扑图（推荐有专门管理软件来维护这个拓扑图，并且还能检查各个节点的健康状态）中进行修改。必要的话还可以为每一个节点实现信任机制，得不到信任的消费者将不能消费。甚至这个工具可以和SHAREPOINT结合，也提供文档的管理。

l 最理想的方式是实现服务的自动部署，全部依靠管理工具来完成，因为在服务器上安装Windows服务，需要复制文件、卸载原来的服务、安装新的服务、服务运行账户的配置，如果服务达到上百个的话，部署的压力也比较大。

l 最后，什么是SOA？个人觉得SOA是提供了系统级的松散组合和重用的基于消息的整合方案。

推荐阅读：《可伸缩性最佳实践：来自eBay的经验》

看图说话：

1、web服务器做负载均衡。即使是做负载均衡也要按功能分割，只有分割了才能有伸缩性。

2、app服务器说实话压力应该不会很大，主要是内存占的多一点。所以一般情况下没有必要做负载均衡，而且一般情况下一个物理

服务器上安装多个服务。比如APP1

如果性能不行的话可以一个物理服务器安装一个服务，比如APP2。如果要做负载均衡的话可以随机选择端点、可以按照主键范围选

择服务等方案。

3、主DB采用SAN和磁盘阵列。其它还有一些类型的服务器，比如外部资源（CDN、google搜索）、文件服务器（不是所有的资源都

需要传到CDN，CDN延时比较大），一般的图片转到专门的文件服务器即可，开放FTP供上传，对外开放HTTP。还有比如邮件服务器

等。

这和SOA没什么关系，只不过提一下物理上的架构。

好，现在拿一个网站做例子，比如认证网站，提供了用户的注册，用户信息向其它区域服务器（比如游戏服务器）激活等功能。上

图想体现的几点是：

1、前面说的，对性能要求特别高的服务，可以以IPC方式进程间通讯。服务当然也就要安装在本地了，无论是WEB服务器还是APP服

务器。

比如说用户在注册的时候需要对某些关键词进行过滤，这个关键词的数据保存在keyword DB，由keyword Service提供关键词的过

滤服务，虽然说在这个服务里面会缓存所有关键词的列表，但是如果需要TCP调用服务的话，跨越网络的性能还是很差的。所以哪

里主机需要，服务就安装在哪个主机上。

2、服务有两种类型，一种是业务服务，比如Passport Service，其余绿色的全部属于基础服务。比如说每一个机器都会有

endpoint service，提供了所有服务的端点信息，我们根据key去定位到服务，如果服务地址需要改，只需要在endpoint db中改变

端点信息，然后重新启动所有机器上的endpoint service即可（为了刷新缓存）。说到缓存刷新方式，一般从来不变的数据可以采

取被动刷新，变化慢的数据可以采取定时主动刷新。那么，重启每一个机器上的基础服务，比如前面说的endpoint服务也很麻烦，

怎么办？每一个安装服务的机器还提供了service management agent服务，这个服务前面说过，一是用于管理机器上的各种服务，

二是用于监控它们，三是这些数据可以汇总到管理C/S程序上（第一个蓝色方块），提供统一的服务管理。还有一种必要的基础服

务就是exception service，提供了统一的记录异常的功能，当然也会有一个异常管理的B/S系统来管理这些异常。

3、每一个服务中都有一个粉红色小方块代表缓存。我想是的说缓存可以在各个层次去做，不一定只有app服务器可以做缓存。sql

server 你给它多点内存就是缓存多点，app上可以做数据的缓存，web服务器上可以做页面的缓存。你可能奇怪，记录异常的服务

不就是把异常插入到数据库吗，缓存什么呢。其实很多异常是重复的，比如有人在攻击你产生的异常，我们在内存中维护不同类型

的异常，相同类型的异常在短时间内比如1小时，不会提交到数据库去记录。

4、再次要提一下一个原则，一个数据库上的服务就像一个罩子，罩在了DB上，其它服务不能穿透这个罩子直接访问下面的数据库

，要访问它的数据只能通过这个服务提供的接口。比如这里的passport service，一来是给passport website去用的，而其它很多

网站也需要会员信息的数据啊？怎么办，就从passport service去拿，不能直接到数据库中去拿。

5、图中棕色的部门是一个异步队列。这里体现了《可伸缩性最佳实践：来自eBay的经验
》中的第四点那就是用异步策略去解耦程序。按照前面一个原则，假设有这么一个场景。用户在中心数据库的数据需要插入到各个

区域的数据库（比如用户激活游戏的过程就是把用户注册时的信息，插入到游戏的数据库中，游戏的数据库在全国各地的）。要访

问游戏数据库，我们肯定是通过专有的game service去做的，不会去直接连接游戏数据库。问题就来了，如果local game db不可

用，game service也不用，而passport service会调用game service去激活用户，那么
passport service这个功能也不可用吗？这2个服务之间产生了很大的依赖，如果在数据库中有一个队列，passport service只需

要把任务信息提交到这个队列表中，这样就可以认为完成了激活任务。那么passport service和game service之间没有直接的依赖

。而game service作为一个队列服务，只需要定时从对列表中获取需要激活的信息，然后真正操作game db去做这个激活就可以了

。完成后再去队列表更新状态就可以了。通过一个异步过程来解除服务之间的耦合。

评论: 23　查看评论　发表评论

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

MCTS Self-Paced Training Kit (Exam 70-503) Microsoft® .NET Framework 3.5—Windows® Communication Foundation 书评

lovecherry — Sat, 01 Nov 2008 07:12:00 GMT

阅读: 1325 评论: 8 作者: lovecherry 发表于 2008-11-01 15:12 原文链接

收到了MVP项目组寄过来的《Microsoft® .NET Framework 3.5—Windows® Communication Foundation》一书，这是一本MCTS考试自学用书。正因为如此，这本书在编排上和一般的技术书不太一样：

1、每一章中的内容是以课为单位的，并且每一课都在光盘中配有相应的练习素材。一般我们在学习的时候都会自己做一些DEMO，仿照书中的例子来实现一些小功能。书中的练习素材一般分BEFORE和AFTER两部分，BEFORE中为我们准备了一个框架，我们在此之上去完成学到的知识点，完成后可以和AFTER进行比较，看看我们做的是不是正确。

2、每一课最后会有课的回顾和总结，其中会有一些练习题。每一章最后也会有章节回顾、章节总结、术语、建议的练习方式等内容。书最后也提供了所有练习题的解答。

3、知识点介绍的比较全，也介绍的比较细。而且其中还穿插了注意、说明、考试技巧、扩展等很多内容。

4、光盘中还提供了模拟考的软件。而且对于所有题目的解答也是非常详细的，并不只是提供了答案。

从内容上说，此书对WCF的介绍也是相当全面的：

第一章的内容围绕契约展开，包括服务契约、服务类型、消息交换方式、双向信道和客户端代理、数据契约、消息契约、数据契约版本控制、序列化控制等内容。

第二章主要介绍了如何公开服务，包括端点的ABC、使用代码和配置文件创建端点、通过端点发布元数据、自定义绑定等内容。

第三章讲述了服务的部署，包括使用IIS、WAS承载服务、创建服务承载工厂、使用控制台应用程序、WINDOWS服务来承载服务等内容。

第四章的内容围绕消费服务展开，包括创建代理和代理类、使用代理调用服务以及消费非WCF服务等内容。

第五章主要介绍了如何配置服务，包括使用声明方式和代码方式配置服务端点、绑定等内容。

第六章讲述了服务的检测，包括WCF跟踪、WCF扩展和WCF的监控等内容。

第七章的内容围绕WCF的基础安全结构展开，包括传输安全、消息安全等内容。

第八章主要介绍了用户级别的安全，包括认证、授权和模拟等内容。

第九章主要介绍了使用POX消息、在客户端处理异常等补充内容。

第十章主要介绍了服务的会话和各种实例模型。

第十一章介绍了服务的事务，包括事务传播、单向调用、嵌套事务、事务超时等内容。

最后的第十二章介绍了WCF的并发模式、同步上下文和回调等内容。

可以看到，前五章介绍了WCF的基础，六到九补充介绍了服务的监控、安全、消息等内容，而十到十二介绍的WCF的实例、会话、事务以及并发是在我们把WCF应用在产品级项目中必须考虑的问题。

本书是一本考试用书，但是并没有任何应试的地方，也很通俗易懂，即使不参加考试，本书也值得你一读。

评论: 8　查看评论　发表评论

编辑推荐：Google Buzz相关新闻

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库