标签：
原来一直使用他人的开源项目框架，异常的定位会很麻烦，甚至不知道这个异常来自我的代码还是这个框架本身。他人的框架有一定的制约性，也有可能是我对那些框架并没深入了解，因为这些开源框架在网上也很难找到高效并且规范的文档。比如别人的框架可能调用了Enterprise Library来实现权限的验证，但在我的项目中，权限验证有可以复用的模块，所以在整合时会非常不灵活。。。。
参考了很多网上的优秀框架，看了几本书后，突然意识到易用才是开发和使用框架的出发点与立足点，框架并不是越复杂越好，评价一个框架的好坏，应综合考虑它的学习成本，使用成本和维护成本。考虑了以上因素后于是打算做一套轻量的框架出来，方便日后的扩充，虽然框架已经非常简单，但依旧可能存在着问题，希望大神们能指点迷津。
我所要面对的项目，并没有特别复杂的业务逻辑，需要面对的最大问题是高并发。这也是我舍弃原有的框架的重要原因。
因为业务逻辑并不复杂，所以采用的dbfirst的设计思路，一方面是项目后续开发时他人好更容易上手，一方面是对于codefirst我也只是停留在会用的阶段，对于高深的DDD，理解还十分有限，可能会引入很多错误的思维方式。
项目的开发环境为：Windows7 SP1、Visual Studio 2013、Sql Server 2012、.NET Framework4.5。
项目依托ASP.NET MVC + WebAPI，数据存储采用EntityFramework。
总体框架
这是项目解决方案的截图，从上到下分为WEB层，Core层，Model层与Infrastructure层，功能分别如下
项目的依赖关系是这样的，使用Autofac注入。原来使用的是spring.net，这次改为更加轻量了Autofac做依赖注入，效率更高（网上说的（-：），也能找到很多的帮助文档。并且Autofac为mvc提供了以每一次请求作为注入依据的方案，将实体以参数的形式传入到控制器中，非常实用。
创建过程
在Entity程序集中，通过数据库生成edmx，这里面也包含了实体对象的模型。接下来就要在core中创建Entities的DbContext实体。
在我原来的系统中，我一般会在EF上在创建一个DAL（数据库访问层），用来存放常用的增删改查的方法，但后来逐渐体会到EF框架本身其实已经很好地封装好了传统DAL层中的方法，如果在放一个DAL层就有重复封装之嫌。这里就不详细讨论这层DAL封装是否有必要，因为不同的人的习惯会不同，如果你是传统三层过来的，也许放个DAL会更得心应手些，当然不放也有不放的好处，比如业务在操作数据库时可以更加灵活，编码时少了层接口也可以显得更加直观。但是不加DAL无法对数据库的操作进行封装，从而应运而生了另一个看似比较棘手的问题，如果日后变更数据库，需要变更core层中的代码吗？这将导致高耦合。这个问题我当初也纠结了很久，但转过来一想，Entity framework是一个开源框架，对主流数据库包括oracle等都已支持，变更数据库只需要重新生成对应数据库类型的edmx，对业务core是没有影响的。
我在业务层创建了一个CoreSession类，用来存放给web的业务操作的集合。
下面是接口，定义了一个公共的savechanges方法，至于干嘛用，我后面会说。
1 public interface ICoreSession 2 { 3 int SaveChanges();
4 }
下面是实现，里面有一个db属性，存放实例后的Entity对象，并最构造方法中新建实例。
1 public class CoreSession:EDUA_ICore.ICoreSession 2 { 3 private DbContext db { get; set; } 4 public CoreSession() 5 { 6 db = new Entity.EDUAEntities(); 7 } 8 public int SaveChanges() 9 { 10 return db.SaveChanges(); 11 } 12 }
一个最简单的core层构建完成了，虽然里面暂时没有任何的方法。接下来要在web层中创建core对象。那么core在web层中能否单例呢？core的单例也就意味着EF实体的单例，因为EF的实例过程在core的构造方法中。而EF本身是不能保证线程安全的。那天在和前辈们讨论EF该不该单例这个问题时，几乎两人同时告诉我千万不要，他们都中过招，如果用最简单的static来实现single，不仅仅是高并发，而是只要并发时就会出问题。当然有另一种方法，用callcontext将core对象放入线程中，每次用时从线程中取，用这种方法来保证EF的线程安全性，这是我用过的一种较靠谱的单例方法，而且暂时还没出过什么问题。但为了保证高并发时的性能，并且借鉴Autofac（Ioc）所提供的机制，我决定采用为每一次请求创建一个Core对象。
我配置Autofac的过程如下
1.下载并引入Autofac的程序集
下载地址：http://autofac.org/
这里需要在WEB引入
这两个程序集，前者是autofac的核心，后者是它的mvc插件，如果需要将注入的映射对象写到配置文件里，还需要引入Autofac.Configuration.dll 这个程序集，由于我直接将映射写在了代码中，所以没有引。
2.在web层中创建RegisterAutofacForSingle类，虽然名字说是single，但只是注册时的single，并不是说将对象单例了。
1 public class RegisterAutofacForSingle 2 { 3 public static void RegisterAutofac() 4 { 5 ContainerBuilder builder = new ContainerBuilder(); 6 builder.RegisterControllers(Assembly.GetExecutingAssembly()); 7 8 //注册给控制器 9 builder.RegisterType<EDUA_Core.CoreSession>().As<EDUA_ICore.ICoreSession>().InstancePerHttpRequest(); 10 11 //注册给过滤器 12 builder.RegisterType<EDUA_Core.CoreSession>().As<EDUA_ICore.ICoreSession>(); 13 builder.RegisterType<Filters.MyAuthorizeAttribute>().SingleInstance(); 14 builder.RegisterFilterProvider(); 15 16 var container = builder.Build(); 17 DependencyResolver.SetResolver(new AutofacDependencyResolver(container)); 18 } 19 20 }
第6行注册了控制器的版本，第9行的方法InstancePerHttpRequest()为每一个新的请求创建一个新实例，后面注册给过滤器的行为中，是全局单例的，因为我的过滤器中不会存在写的操作，不存在并发时的读写问题。
3.在Globa.asax文件中注册Autofac
1 public class MvcApplication : System.Web.HttpApplication 2 { 3 protected void Application_Start() 4 { 5 //注册Autofac 6 RegisterAutofacForSingle.RegisterAutofac(); 7 8 AreaRegistration.RegisterAllAreas(); 9 10 WebApiConfig.Register(GlobalConfiguration.Configuration); 11 FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters); 12 RouteConfig.RegisterRoutes(RouteTable.Routes); 13 BundleConfig.RegisterBundles(BundleTable.Bundles); 14 } 15 }
需要注意的是，由于RegisterAutofacForSingle中给过滤器注册了注入，所以注册Autofac需要放在注册过滤器之前，不然会报错。我把Autofac的注册放在了最前面。
4.在控制器与过滤器中添加core对象实例
1 private ICoreSession iCoreSession; 2 public MyAuthorizeAttribute(ICoreSession iCoreSession) 3 { 4 this.iCoreSession = iCoreSession; 5 }
至此， 在控制器和过滤器中就都可以直接调用到core中的内容了。
在接下去的文章中我会举一个登陆的例子来扩充core层，并且在过滤器中实现权限的判断。
标签：
原文地址：http://www.cnblogs.com/linhan/p/4287059.html
