MVC中业务层是否应该有个基类？它有什么作用？

项目架构Ｎ层结构中，业务层无疑是比较灵活多变，与数据库层紧密联系，又同时约束ＷＥＢ层的中间层，它是否应该有个基类，而如果有，那它的作用又是什么呢？

这就是今天要说的。

首先，我认为每个层都应该有个基类，它的使用当然就是将本层公共的代码进行抽象，可能是属性，方法等等，而对于业务层当然也不例外，先看一下我的业务层基类

serviceBase吧，看代码：

public abstract class ServiceBase
   {
       /// <summary>
       /// Data Repository object

    /// </summary>
       /// <typeparam name="TEntity"></typeparam>
       /// <returns></returns>
       protected virtual IRepository<TEntity> LoadRepository<TEntity>() where TEntity : class,Entity.IEntity
       {
           return new Repository<TEntity>();
       } 
   }
这是一个功能最简单的基类的，它和其它基类一样也是抽象的，即不能直接被实现化的，事实上，直接点说就是它的功能应该叫它的子类去实现，我们通过访问它的子类去使用它的功能，呵呵。

当然我只是举了个例子，事实上项目中还有其它属性和方法应该放在这个类中，那就具体业务具体抽象了，呵呵。我们再看一下它的方法是如何被调用的，看代码：

/// <summary>
    /// User Service Implements
    /// </summary>
    public class UserService : ServiceBase, IService
    {
        #region IService 成é员±

        public IEntity GetModelByPrimaryKey(IEntity entity)
        {
            return base.LoadRepository<Entity.TEST.UserBases>().Find(entity.PrimaryKey);
        }

        public List<IEntity> GetModel()
        {
            return base.LoadRepository<Entity.TEST.UserBases>().GetModel().Cast<IEntity>().ToList();
        }

        #endregion
上面的代码直接使用了父类的LoadRepository方法，其实如果子类有需要，可以在本类中对这个方法进行复写。