Chloe官网及基于NFine的后台源码毫无保留开放
扯淡
经过不少日夜的赶工，Chloe 的官网于上周正式上线。上篇博客中LZ说过要将官网以及后台源码都会开放出来，为了尽快兑现我说过的话，趁周末，我稍微整理了一下项目的源码，就今儿毫无保留的开放给大家，希望能对大家有帮助，献丑了。
项目不大，官网就是几个展示页面。后台借鉴了 NFine 的设计，直接套用了 NFine 的前端模版以及他的一些权限设计。由于个人开发习惯和所用技术与 NFine 的有些不同，比如，NFine 前端数据展示用 jqgrid，而我比较倾向于使用 knockoutjs，同时，后端我也根据自己的一些思想搭建了一个与 NFine 完全不同的架构，所以，基本重写了 NFine 的前端开发模式和后端架构。目前可以在4个数据库间无缝切换（SqlServer、MySql、Oracle和SQLite），主要得益于强大的 Chloe^_^。
后台：
在线体验地址
官网： http://www.52chloe.com/
后台：http://www.52chloe.com:82/
项目介绍
前端主要技术
jQuery：举世闻名的前端类库
knockout.js：MVVM 框架，类似 AngularJS 和 vue.JS
bootstrap：家喻户晓的css
editormd：一个免费开源的 markdown 编辑器，主要用于文档编辑，很好用，推荐
layer：一款近年来备受青睐的web弹层组件。这个还是 NFine 本来就有的，不错的一个组件，我也直接用上了
jquery-plugin-validation：前端数据库验证插件，也是 NFine 本来就有的，很不错，我也保留了下来
后端是用asp.net mvc 5，Newtonsoft.Json，Validator，数据库访问毫无疑问是用 Chloe.ORM。
开发人员都喜欢给自己的框架安个名字，我也不例外，我这个将就叫做Ace吧（海贼王里的艾斯）。我们先看下整个项目架构：
很常规的分层，简单介绍下各层：
Ace：项目架构基础层，有点类似abp里面的abp.dll，里面包含了一些基础接口的定义，如应用服务接口，以及很多重用性高的代码。同时，我在这个文件夹下建了Ace.Web和Ace.Web.Mvc两个dll，分别是对asp.net和asp.net mvc的一些公共扩展和通用的方法。这一层里的东西，基本都是重用度极高的代码，而且是比较方便移植的。
Application：应(业)用(务)服(逻)务(辑)层。
Data：数据层。包含实体类和ORM操作有关的基础类。
Web：所谓的展示层。
整个框架并没有使用repository，原因有三：
* 没理解错的话repository是DDD领域驱动设计里的概念，我这个并不是DDD，我不会为了封装而封装。
* 不是DDD也可以用repository啊！没错，不是DDD也可以有repository。repository设计可以隐藏数据的来源细节，但如果用repository包装了一遍数据库访问组件（ORM），很可能因为一些所谓的设计“规范”会限制ORM框架的发挥，这不是我想要的结果。比如强大的EF，本身对连接查询以及各种功能支持是很好，但经过仓储包装后，可能变得不够灵活了，不知道您是否疑惑包装后该怎么多表连接查询，怎么调用存储过程，我想实现xxx怎么写好？我个人觉得，如果一个设计给开发带来了一定的困扰，就应该考虑设计是否应该存在或合理不合理了。引入一个框架，我们就应该要把它应有的功能发挥的淋漓尽致，不然不如不用。
* repository可以更加方便的切换数据库访问框架啊！这个确实有一定道理，想得很前瞻。然而，我不予考虑。因为得不偿失的行为。为什么这样说？如果项目真的需要换ORM，无非两个原因：1.所用的ORM数据库类型支持的少，而项目要换数据库类型，ORM却不支持新数据库了；2.所用ORM技术太老，就是想换个其他的ORM；3.所用ORM出现了性能瓶颈，拖程序后腿了。如果因为第一个原因而换数据库，那么更多的应该反省项目之初技术选型是否正确，因为Chloe已经友好支持支持了多数据库，所以这个原因在目前我们的项目里不会存在了。第二、三个原因分析：一个项目如果真的需要更换技术，肯定得对代码重构，试想一下，一个项目从开始到完成整个开发周期长还是重构的时间长？前面也说过，对ORM封装了一遍，多多少少会限制了ORM的发挥，开发的时候多多少少不顺，如果为了短时间(相对开发周期)重构的舒适而让整个开发过程饱受各种不爽、不顺折磨，我真的不乐意。再一个，项目一跑起来到项目被淘汰，很可能压根就不会更换ORM，所以，我觉得从方便切换ORM的角度考虑，使用仓储是得不偿失的行为。
以上只是个人对仓储的一些理解，并不完全正确，如有不同看法，还望各位留言探讨。
层层之间需要解耦，引用了什么IOC框架吗？No！IOC很“高大上”，实质就是一个超级大工厂，特色功能就是依赖注入，说白了就是支持有参构造函数创建对象和属性赋值。然而，我个人不大喜欢用注入，因此，我觉得没必要引入IOC框架了。所以我自己建了个超级工厂，充当了IOC容器的角色。
大概实现如下：
View Code程序启动的时候，在启动事件（Application_Start）里会将所有应用服务的实现类给注册进去。这个工厂实现了 IDisposable 方法，因为有些应用服务用完是需要销毁的，所以，这个工厂创建出对象的同时，还承担销毁应用服务对象的职责。
对象到对象的映射框架呢？也No，DTO和实体间转换目前我是傻呼呼的一个一个属性赋值搞的，但以后有可能会引入。
当今流行的repository、IOC和OOM等技术都不用，大家会不会觉得LZ很奇葩或者out了？嘿嘿，我的理念是能减少依赖就尽量减少依赖。减少学习成本同时也可以更好的移植或掌控项目。
对于一个开发框架而言，最基本的就是规范和避免重复编码。虽然我的这个框架简单，但不乏实用技巧点。
框架的一些规范与技巧设计：
ajax请求：对于系统后台，ajax交互是很频繁的事。对于ajax请求的返回数据我制定了基本的状态码和格式
public enum ResultStatus
{
OK = 100,
Failed = 101,
NotLogin = 102,
Unauthorized = 103,
}
public class Result
{
ResultStatus _status = ResultStatus.OK;
public Result()
{
}
public Result(ResultStatus status)
{
this._status = status;
}
public Result(ResultStatus status, string msg)
{
this.Status = status;
this.Msg = msg;
}
public ResultStatus Status { get { return this._status; } set { this._status = value; } }
public object Data { get; set; }
public string Msg { get; set; }
}
序列化成json大概是这样子：{"Data":{},"Status":100,"Msg":null}
同时，为了避免频繁new这个Result类，我在web层的 BaseController 中增加了很多有关方法：
protected ContentResult JsonContent(object obj)
{
string json = JsonHelper.Serialize(obj);
return base.Content(json);
}
protected ContentResult SuccessData(object data = null)
{
Result<object> result = Result.CreateResult<object>(ResultStatus.OK, data);
return this.JsonContent(result);
}
protected ContentResult SuccessMsg(string msg = null)
{
Result result = new Result(ResultStatus.OK, msg);
return this.JsonContent(result);
}
protected ContentResult AddSuccessData(object data, string msg = "添加成功")
{
Result<object> result = Result.CreateResult<object>(ResultStatus.OK, data);
result.Msg = msg;
return this.JsonContent(result);
}
protected ContentResult AddSuccessMsg(string msg = "添加成功")
{
return this.SuccessMsg(msg);
}
protected ContentResult UpdateSuccessMsg(string msg = "更新成功")
{
return this.SuccessMsg(msg);
}
protected ContentResult DeleteSuccessMsg(string msg = "删除成功")
{
return this.SuccessMsg(msg);
}
protected ContentResult FailedMsg(string msg = null)
{
Result retResult = new Result(ResultStatus.Failed, msg);
return this.JsonContent(retResult);
}
这样，我们在Action中可以直接这样用：
[HttpGet]
public ActionResult GetModels(Pagination pagination, string keyword)
{
PagedData<Sys_User> pagedData = this.CreateService<IUserAppService>().GetPageData(pagination, keyword);
return this.SuccessData(pagedData);
}
[HttpPost]
public ActionResult Add(AddUserInput input)
{
this.CreateService<IUserAppService>().AddUser(input);
return this.AddSuccessMsg();
}
[HttpPost]
public ActionResult Update(UpdateUserInput input)
{
this.CreateService<IUserAppService>().UpdateUser(input);
return this.UpdateSuccessMsg();
}
[HttpPost]
public ActionResult Delete(string id)
{
this.CreateService<IUserAppService>().DeleteAccount(id);
return this.DeleteSuccessMsg();
}
[HttpPost]
public ActionResult RevisePassword(string userId, string newPassword)
{
if (userId.IsNullOrEmpty())
return this.FailedMsg("userId 不能为空");
this.CreateService<IUserAppService>().RevisePassword(userId, newPassword);
return this.SuccessMsg("重置密码成功");
}
通过vs强大的智能提示，直接 this. 就可以出来，省了不少事。
尽量"少的使用using":
在.net的规范中，对于任何实现了 IDisposable 接口的类，用完我们都应将其销毁掉。在项目开发中，如果充斥着太多的 using 写法，我是非常烦的，我想大家也是同样的感受，比如 DbContext。但如何避免使用 using，但又保证对象最终又被销毁呢？如果大家用了一些IOC框架，估计不需要太多的关心对象的销毁问题，因为IOC容器帮大家做了这些事。我不用IOC，那该咋办呢？其实不难，就拿 DbContext 举例。在我这个架构中，应用服务层是直接操作 DbContext 的，我建了个应用服务基类（AppServiceBase），DbContext 的创建和销毁交给 AppServiceBase 就行了。因此，这又引申了一个规范，每个应用服务必须实现 IDisposable 接口(一个类内部如果有 IDisposable 的对象，我觉得该类也应该实现 IDisposable 接口)！
public abstract class AppServiceBase : IAppServiceFactoryProvider, IDisposable
{
IDbContext _dbContext;
protected AppServiceBase()
: this(null)
{
}
protected AppServiceBase(IAppServiceFactory serviceFactory)
{
this.ServiceFactory = serviceFactory;
}
public IAppServiceFactory ServiceFactory { get; set; }
public IDbContext DbContext
{
get
{
if (this._dbContext == null)
this._dbContext = DbContextFactory.CreateContext();
return this._dbContext;
}
set
{
this._dbContext = value;
}
}
public void Dispose()
{
if (this._dbContext != null)
{
this._dbContext.Dispose();
}
this.Dispose(true);
}
protected virtual void Dispose(bool disposing)
{
}
}
然后子类应用服务就可以直接 this.DbContext 这样毫无顾忌的使用 DbContext 了，再也不用关心 DbContext 是如何创建和被销毁了。技巧虽小，却给我开发便利了许多。
所有应用服务是由前面提到的超级工厂创建的，所以，我的超级工厂也需要实现 IDisposable 接口，目的就是为了掌管其创建出的应用服务对象。那么问题来了，LZ你使用的超级工厂对象的时候还不是得要销毁你的超级工厂，不用 using 怎么做？哈哈，这个问题用同样的基类方式就可以解决。
不知道大家是否留意MVC的 Controller 这个类也实现了 IDisposable 接口，它提供了一个 Dispose(bool disposing) 方法的重载！对于这个重载方法，我们好好利用它就行，嘿嘿~
我们建的 Controller 都会继承于我们自定义的 BaseController 中，BaseController 则重写了 Dispose(bool disposing) 方法，用于销毁一些我们自定义的 IDisposable 对象：
public abstract class BaseController : Controller
{
static readonly Type TypeOfCurrent = typeof(BaseController);
static readonly Type TypeOfDisposableAttribute = typeof(DisposableAttribute);
protected override void Dispose(bool disposing)
{
base.Dispose(disposing);
this.DisposeMembers();
}
[Disposable]
AppServiceFactory _appServicesFactory;
IAppServiceFactory AppServicesFactory
{
get
{
if (this._appServicesFactory == null)
this._appServicesFactory = new AppServiceFactory(this.CurrentSession);
return this._appServicesFactory;
}
}
protected T CreateService<T>(bool managed = true) where T : IAppService
{
return this.AppServicesFactory.CreateService<T>(managed);
}
/// <summary>
/// 扫描对象内所有带有 DisposableAttribute 标记并实现了 IDisposable 接口的属性和字段，执行其 Dispose() 方法
/// </summary>
void DisposeMembers()
{
Type type = this.GetType();
List<PropertyInfo> properties = new List<PropertyInfo>();
List<FieldInfo> fields = new List<FieldInfo>();
Type searchType = type;
while (true)
{
properties.AddRange(searchType.GetProperties(BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.DeclaredOnly).Where(a =>
{
if (typeof(IDisposable).IsAssignableFrom(a.PropertyType))
{
return a.CustomAttributes.Any(c => c.AttributeType == TypeOfDisposableAttribute);
}
return false;
}));
fields.AddRange(searchType.GetFields(BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.DeclaredOnly).Where(a =>
{
if (typeof(IDisposable).IsAssignableFrom(a.FieldType))
{
return a.CustomAttributes.Any(c => c.AttributeType == TypeOfDisposableAttribute);
}
return false;
}));
if (searchType == TypeOfCurrent)
break;
else
searchType = searchType.BaseType;
}
foreach (var pro in properties)
{
IDisposable val = pro.GetValue(this) as IDisposable;
if (val != null)
val.Dispose();
}
foreach (var field in fields)
{
IDisposable val = field.GetValue(this) as IDisposable;
if (val != null)
val.Dispose();
}
}
}
注意看，上面的 BaseController 有一个 CreateService 方法，用于创建应用服务对象。然后呢，子类的操作方法中，我们就可以毫无顾忌的调用 this.CreateService 方法创建相关的应用服务了：
[HttpPost]
public ActionResult Add(AddUserInput input)
{
this.CreateService<IUserAppService>().AddUser(input);
return this.AddSuccessMsg();
}
如果您从github下载了源码就会发现，源码中using关键字少之又少~
管理每个View对应的js文件：
对于后台开发，基本上每个页面都需要js支持，但我们又不想js代码和html放在一个窗口里开发，所以大家都习惯建一个js文件，然后在页面中引用就行了。在 webform 时代，我们都习惯将页面和其对应的js文件放在同一个文件夹中，方便！！但在mvc默认设置中，views文件夹下是不允许放js文件的，这可咋办呢？？虽然有设置可以让views文件夹里的js文件可以被访问，但，我不想打破mvc的默认规则！因此，我用了个投机取巧的办法，就是利用mvc的部分视图功能。我把js代码写在部分视图中，然后页面中直接以@Html.Partial("Index-js")的方式引用，如下：
这样一个页面就能和它对应的js文件成双对的在同一个文件夹中了，实现了js代码和 html 代码可以分开！但有一点要注意，最终的页面输出到浏览器的时候 html 和 js 代码是混在一起的！那么问题来了，你这样干会影响页面加载速度，并且没能充分利用浏览器对静态资源的缓存啊~在一些技术群里，我跟他们说出我的这个设想和做法时，有不少人提出了这样的质疑~其实，对于一个后台页面而言，这点影响不足为惧，并没有想象中那么大。这其实是个智仁问题，我也不多解释了，利弊自己权衡就好。没有绝对好的设计，只要实用和适合自己就够了！~
结语
每个人都梦想有个属于自己的开发框架，我也一样。目前的Ace框架虽然简单，在大牛面前不值一提，但还是希望能对一些人有帮助。
官网使用的是 SQLite 数据库，GitHub 项目中已经有了相应的db文件，只要你本地装了asp.net环境，下载即可运行。考虑到很多同学对 SQLite 不熟悉，以及大家装的是 SqlServer、MySql 或 Oracle，我也给大家准备好了所有的相关dll以及相应的数据库脚本，只要建个数据库，然后运行脚本就可以创建相关的表了。框架已经支持4种数据库之间随意切换，所以，大家在web.config里设置下数据库类型和数据库连接字符串就可以运行了(web.config都有修改说明)。试问，世上这么热心的程序员，除了博主还有谁？如果这都换不来您的一个推荐，博主我真的无语问苍天，是时候考虑关闭博客了555~
技术教程或心得我倒不是很擅长写，我只想把日常开发的一些干货分享给大家，您的推荐是我分享的最大动力。同时，如果您对 Chloe 这个项目感兴趣，敬请在 Github 关注或收藏(star)一下，以便能及时收到更新通知。也欢迎广大C#同胞入群交流，畅谈.NET复兴大计。最后，感谢大家阅读至此！同时也非常感谢 NFine 作者给咱们提供了一个那么好的一个开发框架！
Chloe 官网及后台源码地址：https://github.com/shuxinqin/Ace