在你设计一个方法的时候，无法直接从方法参数或实例成员(字段或属性)获得的所有信息都是上下文。例如：

• 当前用户是谁？
• 刚才提供操作的数据库连接实例从哪里拿到？
• 这个方法从哪个 View 或者哪个 Controller 调用的？

当然，在方法体中获得上下文最终还是要靠方法参数或实例成员。

在MVC中有大量的上下文信息，例如：

• ControllerContext
• ViewContext
• ModelBindingContext
• ExceptionContext
• ActionExcutingContext
• ActionExcutedContext
• AuthorizationContext
• ResultExcutingContext
• ResultExcutedContext

这些上下文通过单一的参数提供了丰富的运行时信息。

实体上下文放到哪里？

除了MVC的上下文外，还有一个重要的上下文就是 ADO.NET EF的实体上下文，通常派生自System.Data.Objects.ObjectContext，都是由IDE自动生成的。这个上下文承载了数据库连接，需要通过IDisposable来释放连接。多数情况下，我们这样使用：

using(MyEntities context = new MyEntities())
{
…… 在这里写入代码
}

如果在一次页面生命周期内只使用一次实体上下文这样处理是非常合适的，但是事实上不都是这样。更多的时候可能需要临时对实体进行一个小的访问，例如获得一个当前用户的显示名，通过这种方式访问就代价太大了。

我们知道，这个上下文可以存放到HttpContext里。在HttpContext的所有容器中，只有Items是最合适的，因为这个属性的存续期在后台页面对象释放后就结束了。当然，被释放时也不会执行IDisposable的Dispose方法。我们仍然需要在Global.asax中捕捉EndRequest事件。但是奇妙的是：在ASP.NET MVC Application中不能使用event方式来捕捉，只能手工写Application_EndRequest方法。

什么是一次Model、二次Model和Form Model？

Model一共分为三种：

• 直接数据库实体映射实例，如Product(产品)
• 为View的呈现提供服务的包装对象，如ProductInfo(产品信息)
• 为Post回传提供服务的包装对象，如ProductForm(产品属性值)

第一种类型Model的特点是非常浓缩，几乎没有冗余，通过复杂的关系进行组合，通常需要通过多个不同类型的实例进行组合来表达一个完整的有意义的场景。例如，一个产品信息可能包含产品名称、产品类别、该产品所有的规格型号以及每种规格型号的参数、单价等。虽然ADO.NET EF提供了获取组合属性的能力，但不能处理多层次，并且不能对加载过程进行控制。所以，需要专门定义一些Model对这一组Model进行包装。如果把原始的模型称做“一次Model”，则可以把这个包装对象称做“二次Model”。

页面上收集到的Form信息，通过三种方式传递到Controller(以登录为例)：

• 每个信息项一个参数：public ActionResult Login(string userName, string password){…}
• 一个单一的名值对参数：public ActionResult Login(FormCollection formCollection){…}
• 一个单一的包装对象：public ActionResult Login(LoginInfo info){…}

第一种方式不利于重构。当需要加入一个参数时，必须修改Action的签名。而且也无法令Controller把值传递到View。第二种方式不利于设计时纠错，因为FormCollection中的值不是强类型的。所以，我们通常都会采用第三种方式。虽然ADO.NET EF对象可以直接作为Form Model，并且有BindAttribute对属性与Form值进行定制化的绑定，但是不够灵活，如果一个Form组合跨多个一次Model类型，则根本无法处理。所以我们有必要专门定义一个Model给View使用。我们不妨称之为“Form Model”。

业务逻辑放到什么地方？

MVC是一种“古老”的设计模式，提供了非常自然的分层方式，这也是为什么利于单元测试的原因。除了MVC这些“主层”以外，BLL可以算是一个“亚层”。那么，我们把BLL放到什么地方最合适？

BLL需要完全可见Model层，同时也需要一些上下文信息。例如，我们至少从我们刚才描述的论题中发现，需要从HttpContext的Items中获得实体上下文。有些时候，我们还需要将用户的一些登录信息缓存到HttpContext中，如果用户的登录信息非常复杂的话，仅仅依靠HttpContext.User.Identity.Name每次去抓取未必很合算。我的习惯是把和这个用户相关的信息组合到一个大的Model对象中，并把这个对象的实例 存放到HttpContext.Cache中。如果有任何变化，释放这个Cache项即可。

所以，对于业务逻辑的位置你可以有两个选择：

• 放到 Model 下，再建立一个“上下文提供器接口”，由 Model 借助上下文来独立处理。
• 放到 Controller 下，直接使用 Controller 提供的上下文来进行处理。

第一种方式不依赖Controller，解耦彻底，非常灵活，更易于测试。但是需要付出一定的成本，调用栈会稍深一点，还需要劳神处理到Controller与BLLContext间的关系。第二种方式解耦不够彻底，但非常简捷，比较适合 Controller 与 Model 不必彻底解耦的小型项目。有意思的是：ASP.NET MVC Application模板所生成的AccountController采用的就是第二种方式。

ADO.NET EF仅影响ASP.NET MVC的Model层。在Model层中除了EDMX自动生成的一次Model外，我们还需要建立大量的二次Model和Form Model。当然，从提升内聚度考虑，所有的业务逻辑方法都在这些Model中定义，特别是，可以利用partial类和扩展方法这两种手段加入业务逻辑。

参考了以下文档：

A.实现一个Ajax模式的文件上传有多难？ 

B.ASP.NET MVC 檔案上傳下載是很方便的

如果你也有这样的需求，你不妨直接下载下来看看。

再讲多两句话。

第一句话，由于HttpPostedFileBase本身已经区分了文件的MIME类型，所以在生成插入到tinyMCE元素的时候会根据是否为image来确定是<img>元素还是<a>元素。这一点可供参考文档A反参考。

第二句话， 不知道是基于什么原因，asp.net mvc的JavaScriptResult会给输出补上<pre>元素，导致脚本不能在嵌套页面中自动运行。

看到园友写的“ ORM是进化还是倒退？”的文章，禁不住想说上几句。其实进化(或者进步?)或者倒退(或者退化?)是没有一个清晰标准的，追求这个进步或者倒退实在也没有什么意义。但是这个标题很惹人，很多年轻人很容易受到蛊惑，所以我必须站起来提醒一下他们。

ORM可以理解成object-relation-mapping，其实结构就是api-database-model。很多人理解的ORM就是database→model→api。事实上这样很自然，一直以来大家都是从数据库设计开始一个系统的。所以各种基于数据库的代码生成器非常盛行，以至于linq2sql和ADOEF(或者有人叫linq2entity)也是数据库先行。但是我之前所经历的ORM却反而鲜见这种模式，所以我一直都没有习惯过来。

最早接触ORM这个词，还是在1999~2001年前后混迹大富翁论坛的时候(那应该也是大富翁论坛最鼎盛的时候)。有一群牛人把java中的一些概念搬到Delphi上，的确让人大开眼界。现在去看，还能看到过去的一些痕迹。没有多久，Delphi上有了正式的ORM产品。首先出炉的是一个叫ModelMaker的MDA工具，有自己的Modeling GUI，从建模到api，浑然一体。MM以后，Bold for Delphi也慢慢火起来，这个基于UML的东东没有自己的Modeling GUI，但是可以使用当时流行的Rose或Together建模的成果。无论是MM还是BFD，都完全当数据库是一个透明的东西。这一类ORM模式是model→api→database，你几乎没有机会干预数据库的定义、生成 和操作。我说这是“纯”的orm。纯倒是纯了，彻底的OO了，但是你回头看一下生成的数据库，无字天书，比现如今sharepoint生成的数据库还丑陋。遇到想做数据挖掘的用户，只能是欲哭无泪了。在这方面，我承认其后来者ECO有了明显的改善，所以我一直相信ECO是一个伟大的产品，只是我用不起而已。

我认识Hibernate是在2003年，后来我一直当Hibernate是JDO的一个非EJB解决方案。Hibernate的确是按配置行事，先有数据库，当时仍然需要手工写一堆entity代码。一群懒人不屑做一些简单重复的事情，自动生成这些配置文件，从此开了“代码自动生成”的先河。哈哈，如果你讨厌“自动代码生成”，去找这些家伙们算账吧，他们身在曹营心在汉，搞java的居然做这么m$的事情，受点委曲也是应该的。所以，Hibernate是一个兼顾database的方案，也是database→model→api，尽管这个api其实是一堆配置。

你烦了当数据库变化以后，model和api的自动同步，我可以接受。不过想一想呢，同步model和api总是有一些好的解决方案。如果你用面向过程的方式，model是没有了，不需要同步了，但是那些api可都是一堆堆的sql语句，我不知道你可以用什么方式来同步。所以，无论OO也罢，PO以罢，进化也好，退化也好，都不是你想讨论的。你无非想要一个比较敏捷一点的方案罢了，如果你喜欢OO，当然你会选择ORM；反之，如果你喜欢PO，你也可以创造一个PRM(procedure-relation-mapping，我相信这个东东一定是可以做到的)。所以，不要告诉我什么OO与Database不匹配的话题，虽然我中意OO但我从来都认为db4o不会成功。database和OO所解决的问题完全不在一个领域，两者的功能是无法相互替代的。

我可是在.net下用了N年的ORM，虽然跌跌撞撞也罢，至少我明白我要的是什么，而市面上的东西其中缺什么。对于我来说，好的ORM产品必须具备以下因素：

• 必须一切从模型开始，无论你是UML也罢，ER也罢，都可以。有Modeling GUI也好，没有的话Hosting一个Addin到IDE也行。
  
• 必须有自动代码生成，并且既能生成api代码，也能生成sql脚本。当你的数据模型变化以后，改完model，你只需要按几个键，然后所有的一切都有工具帮你搞定(当然包括数据库结构重定义和测试数据自动导入)。
  
• 功能上必须提供足够的数据操作，性能可靠。必须支持引用、继承和关联三种关系，且继承关系必须是一表一类。
• 除了能传递数据，还必须能够传递“条件包”，当然，运行时的东东，可以是linq的expression也可以是hibernate的criteria。这是分层操作和分布式操作所必须的。
  
• 虽然通用的方式是以实体为类型、数据行为实例，也可以是以实体为组件(component)，而隐含行，但需要确保引用、继承和关联关系。

检查一下ADOEF，头一条就不符合，所以我只能放弃。ORM不会为我提供最好的性能、最好的设计，但是因为其敏捷性，会为我提供最好的产能，特别是在业务复杂的时候。如果不是为了产能，ORM也没有什么生命力。

别嚷嚷ORM不是万能的。谁都没有说过有什么东西是万能的。如果你都不访问数据库，你当然不需要ORM了，所以不会有人说ORM是万能的。只有傻瓜才相信有人真的说过。

• ChangeServiceConfig2
• QueryServiceConfig2
• EnumServicesStatusEx
• QueryServiceStatusEx
• RegisterServiceCtrlHandlerEx
• NotifyServiceStatusChange
• ControlServiceEx

这些函数在最新版本的MSDN文档中有详细记载。这些改进对我们编写Windows服务的主要影响有：

首先，最大的好处在于，以往在ServiceMain中调用RegisterServiceCtrlHandler的时候，所注册的ServiceController例程只有一个参数，就是控制码。在很多情况下，这是不够的。换句话说，如果需要注册一段共享的ServiceController代码，是无法做到的。例如Delphi的Windows服务架构在处理这个问题的时候就不太方便，一个Windows服务应用程序就只有有一个ServiceController例程，并且该例程只能访问全局上下文。而新的RegisterServiceCtrlHandlerEx所注册的ServiceController例程一共有四个参数：控制码、事件类型、事件数据和外部上下文。特别是这个上下文，非常方便在ServiceController中访问单独的私有的类实例代码。我没有Delphi2007的WinSvc的源码，但我根据编译时的提示，判定估计该类库没有更新。

其次，在调用ControlService的时候，只能控制服务的状态，而ControlServiceEx还可以加注进行这些控制的原因。

再次, QueryServiceStatusEx可以查询相关进程的信息。

最后，在登记Windows服务后，可以进一步修改配置，例如，Delphi的Windows服务架构无法设置Windows服务的描述。JEDI类库虽然也可以设置描述，但是却是通过修改注册器来实现的。而ChangeServiceConfig2可以很简单地解决这个问题。此外，还可以设置在Windows启动或停止失败后，可以指定运行某个活动(例如，可以重启或者执行某个命令)。

附件中文件包括一个源文件和一个DCU文件，在Delphi7下测试通过。最简单的办法是：将WinSvc.Pas文件复制到C:\Program Files\Borland\Delphi7\Source\Rtl\Win下，将WinSvc.dcu文件复制到C:\Program Files\Borland\Delphi7\Lib下，分别替换掉原来的文件即可(安全起见，建议将原来的文件换个名称备份)。