前面项目的层次和调用关系都说明了，关系如下图
采用三层架构的时候，研究过BLL层的必要性，觉得业务逻辑完全可以在controller里实现，没有必要单独做一个项目，另一个分层多了会影响性能。后来我还是把业务逻辑独立出来，原因如下：
业务逻辑写进controller里代码看着比较混乱，时间久了代码容易理不清。
在controller里直接写逻辑重复代码会不较多，开发效率低。
分项目有利于代码重用，有时候可以直接拿到其他项目中稍作修改就可以用。
对于性能我觉得分层多了肯定会有影响，但是不会很大。现在硬件的更新速度远大于软件，对业务逻辑处理起来很轻松，多实例化几个类对性能影响不大。一般来说网站运行基本上是一个存数据库和取数据库的过程，业务逻辑还是比较少，只不过现在的网站使用的图片、动画更多，效果更加绚丽。我觉得网站的效率瓶颈主要出现在服务器的带宽、IO性能和存取数据库上。在代码方面能做的就是优化数据库的存取。对了一般项目来说，为了百分之几的运行效率远不如提高开发效率和更加容易的代码管理重要，能实现需求就好，运行效率是哪是大牛要做的事。
对IDAL、DAL、IBLL 、BLL这四个项目：
IDAL写一个Base接口，接口中固定几个数据库操作方法，其他接口都继承自这个接口；
DAL项目做个base类实现这个IDAL的base接口，其他类都继承自base类。
同样IBLL中也写一个Base接口，固定几个基本的操作方法，同样其他接口也继承自这个base接口
IBLL中也写一个base类来实现IBLL中的base接口，其他类继承自这个base类。
这里以对用户的操作来构建代码的基本模式：
一、模型
这里写三个模型类。打开Ninesk.Models分别添加User、UserGroup、UserConfig三个模型类。
1、用户模型—User类
用户模型或者叫账户模型，为什么这么说看下面代码
using System; using System.ComponentModel.DataAnnotations; namespace Ninesky.Models { /// <summary> /// 用户模型 /// <remarks> /// 创建：2014.02.02<br /> /// 修改：2014.02.05 /// </remarks> /// </summary> public class User { [Key] public int UserID { get; set; } /// <summary> /// 用户名 /// </summary> [Required(ErrorMessage="必填")] [StringLength(20,MinimumLength=4,ErrorMessage="{1}到{0}个字符")] [Display(Name="用户名")] public string UserName { get; set; } /// <summary> /// 用户组ID /// </summary> [Required(ErrorMessage = "必填")] [Display(Name = "用户组ID")] public int GroupID { get; set; } /// <summary> /// 显示名 /// </summary> [Required(ErrorMessage = "必填")] [StringLength(20, MinimumLength = 2, ErrorMessage = "{1}到{0}个字符")] [Display(Name = "显示名")] public string DisplayName { get; set; } /// <summary> /// 密码 /// </summary> [Required(ErrorMessage = "必填")] [Display(Name = "密码")] [DataType(DataType.Password)] public string Password { get; set; } /// <summary> /// 邮箱 /// </summary> [Required(ErrorMessage = "必填")] [Display(Name = "邮箱")] [DataType(DataType.EmailAddress)] public string Email { get; set; } /// <summary> /// 用户状态<br /> /// 0正常，1锁定，2未通过邮件验证，3未通过管理员 /// </summary> public int Status { get; set; } /// <summary> /// 注册时间 /// </summary> public DateTime RegistrationTime { get; set; } /// <summary> /// 上次登陆时间 /// </summary> public DateTime LoginTime { get; set; } /// <summary> /// 上次登陆IP /// </summary> public DateTime LoginIP { get; set; } public virtual UserGroup Group { get; set; } } }
这个模型类中只包含用户名、密码、用户组、显示名、邮箱等属性，纯粹是基本的账户信息，目的是让用户注册的时候尽可能的少填信息。其他信息如果需要可以再写新类与账户进行关联，用户需要的时候登录后再进行补填（如：资本资料、个人信息、联系方式等。这里先不考虑这些）。这里的显示名根据需要可以做昵称、真实姓名等来使用。
2、用户组模型—UserGroup类
这个类注意下GroupType，这个用来对用户组进行一下分类的，方便管理，其实没什么特别的意义。我的想法是普通类型就放普通的注册用户的组，如果大的网站允许用户升级的话，限定在这个类型的用户组内。特权组可以放一些vip之类的用户组，需要管理员给予，区别普通用户组，但又没有管理权。管理类型的用户组需要后台管理员给予，可以对文章、评论、咨询进行管理。