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 ServiceBaseIService
    #region public IEntity IEntity return baseUserBasespublic ListIEntityreturn baseUserBasesIEntity#endregion

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

本文转自博客园张占岭（仓储大叔）的博客，原文链接：MVC中业务层是否应该有个基类？它有什么作用？，如需转载请自行联系原博主。