关于两个MVC示例的思考(MVCStore和Oxite)-低调大师

关于两个MVC示例的思考(MVCStore和Oxite)

2017-11-13 587

最近看了一些关于MVC框架的东西，加以之前就研究过一些关于 MVC架构的信息，碰巧在网上又看到了这样一篇文章，是关于微软内部的开发者对Oxite项目的个人攻击，让我产生了写篇文章来表达一下自己对于这种架构模式的思考。

    声明，如果之前没看过这两个项目的朋友建议下载相应的源码：
    MVCStore：[url]http://www.codeplex.com/mvcsamples[/url]
    Oxite：[url]http://www.codeplex.com/oxite[/url]

    好了，开始今天的正文:)

1.Controller干了些什么

   先说一下我的看法，这个所谓控制器的最大作用应该是“控制和调度”，控制即前台视图(view)的显示(显示那个视图), 调度即执行相应的业务逻辑 (在这两个项目中就是那些Services，而Services即完成对model数据模型的封装调用，并实现相关的业务逻辑)。这里业务规则如何定义应该是在Services里进行，与Controller无关。

      就其工作性质而言还是比较简单的，因此简要的工作内容就应该有简单的实现 (指代码)，这里可以看看MVCStore是如何搞的，请见下面代码：

(摘自Commerce.MVC.Web"App"Controller"AuthenticationController.cs）：

public class AuthenticationController : Controller
{

.
         public ActionResult Login()
        {
             string oldUserName = this .GetUserName();

             string login = Request.Form[ " login " ];
             string password = Request.Form[ " password " ];

             if ( ! String.IsNullOrEmpty(login) && ! String.IsNullOrEmpty(password))
            {
                var svc = new AspNetAuthenticationService();
                 bool isValid = svc.IsValidLogin(login, password);

                 // log them in
                 if (isValid)
                {
                    SetPersonalizationCookie(login, login);

                     // migrate the current order
                    _orderService.MigrateCurrentOrder(oldUserName, login);

                     return AuthAndRedirect(login);
                }
            }
             return View();
        }

}

一看便知这是一个登陆验证操作，其使用Request.Form方式从表单中获取数据，这里暂不说其获取的方式优不优雅（因为与本文要聊的内容关系不大）。可以看出其实现的过程也之前采用webform方式开发出现的代码也差不多，只不过是将相应的login.aspx.cs中的操作放到这controller中，这种好处主要就是将原本分散但功能上应该同属于认证的类（Authentication类是按架构设时划分出来的）放置在了一起，这样在代码分布上会更合理一些。另外就是进行单元测试时也会很容易编写测试代码。当然还有好处，我想就是将那些经常变化的代码使用这种方式约束在了controller中，为将来的后续开发，特别是维护以及查找BUG上会有一个比较清晰的
范围。

当然在看Oxite代码时，这块会有所差异，即Oxite使用了IModelBinder来实现将表单中的数据绑定到相应的类上以完成Model中（实体）类的初始化绑定工作，如下:

public class UserModelBinder : IModelBinder
{
     public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
    {
        Nam.ueCollection form = controllerContext.HttpContext.Request.Form;
        User user = null ;

        Guid siteID = Guid.Empty;
         if ( ! string .IsNullOrEmpty(form[ " siteID " ]))
        {
            form[ " siteID " ].GuidTryParse( out siteID);
        }

         if (siteID == Guid.Empty)
        {
            user = new User
            {
                Name = form[ " userName " ],
                Email = form[ " userEmail " ],
                DisplayName = form[ " userDisplayName " ],
                Password = form[ " userPassword " ]
            };

            Guid userID;
             if ( ! string .IsNullOrEmpty(form[ " userID " ]) && form[ " userID " ].GuidTryParse( out userID))
            {
                user.ID = userID;
            }
        }

         return user;
    }
}

     其实这种做法有一定的好处，就是将这类在功能上类似的操作进行了封装。比如大家可以想像通过web请求提交过来一个大表单，上面有几十个字段属性（不要问我为什么会有这种大表单），而如何将这些字段绑定的操作与controller中接下来的业务流程操作放在一起，会让controller中的相应方法代码长度增长过快，所以倒不如通过上面这个方法将相应的实体类与Web页面信息的绑定工作分离出来，当然 Oxite使用声明相应UserModelBinder类的方式进行封装的做法还有待商榷。

     说来说去，还是如Rob Conery所说的，要始终保持用Controller与View的轻快，易于测试这一原则。这一点其实正与SOA架构中的一些思想相符合，下面结合我的理解来解释一下：

     在SOA中,有组件(component)的概念，即组件是业务逻辑的原子级功能操作，其按照高内聚低耦合的方式进行设计，当业务流程开发运作时，其工作原理就是正确组合相应的业务组件来实现相应的应用。这样的好处就是可以将这些组件分布式布署，同时当业务流程发生变化时，只要调整相应的业务流程逻辑（soa中称为bpel）即能够快速响应业务变化。而如何构造这种可重用的组件在SOA中也是有相应规范的，被称为 SCA .

     说到这里有些远了，那在MVC架构中又有什么类似的思想呢？其实在这里controller的一些设计要求与SOA中的bpel有着相似的设计理念，即完成对业务组件（即MVCStore解决方案中的Commerce.Services项目下的相应文件）的流程
编排和调用。这样即便将来需求变化，而导致了业务流程的变化（不是业务规则变化），也只是修改Controller这一层应该可以满足了，而正确而快速的修改的“前提”，应该就是该Controller应该设计得“ 尽可能的轻快 ”。


2.需求变化了，导致了业务规则变化怎么办？

     正如Ivar jacbson 在传授“明智开发”模型时所说的那样， “软件开发中不变的是--需求的不断变化” 。这一点相信大家是有强烈共鸣的。

     这里我们先来简单的看一下MVCStore和Oxite的处理方式，从设计思路上两个项目基本一致，即使用接口分离方式来应对这种变化。比如：Oxite"Services"中就有这样的代码：

public class UserService : IUserService
{
       private readonly IUserRepository repository;
       private readonly IValidationService validator;

       public UserService(IUserRepository repository, IValidationService validator)
      {
           this .repository = repository;
           this .validator = validator;
      }

       #region IUserService Members

       public User GetUser( string name)
      {
           return repository.GetUser(name);
      }

       public User GetUser( string name, string password)
      {
          User user = string .Compare(name, " Anonymous " , true ) != 0 ? repository.GetUser(name) : null ;

           if (user != null && user.Password == saltAndHash(password, user.PasswordSalt))
               return user;

           return null ;
      }

       public void AddUser(User user, out ValidationStateDictionary validationState, out User newUser)
      {
          validationState = new ValidationStateDictionary();

          validationState.Add( typeof (User), validator.Validate(user));

           if ( ! validationState.IsValid)
          {
              newUser = null ;

               return ;
          }

.
}

其实现了IUserService服务接口。

而MVCStore中的Commerce.Services项目中的代码也使用了类似接口定义，比如：

[Serializable]
public class OrderService : Commerce.Services.IOrderService {

    IOrderRepository _orderRepository;
    ICatalogRepository _catalogRepository;
    IShippingRepository _shippingRepository;
    IShippingService _shippingService;

     public OrderService() { }
     public OrderService(IOrderRepository rep, ICatalogRepository catalog,
        IShippingRepository shippingRepository, IShippingService shippingService)
    {
        _orderRepository = rep;
        _catalogRepository = catalog;
        _shippingRepository = shippingRepository;
        _shippingService = shippingService;
    }

     /// <summary>
     /// Gets all orders in the system
     /// </summary>
     /// <returns></returns>
     public IList < Order > GetOrders() {
         return _orderRepository.GetOrders().ToList();
    }

.
}

定义并实现这些服务接口之后，就可以通过IOC这类方式来实现最终的注入，以决定在程序运行时使用那些具体实现类了，比如Oxite中的Oxite/ContainerFactory.cs是这样进行注册的( 使用了Unity框架 ):

public IUnityContainer GetOxiteContainer()
{
     IUnityContainer parentContainer = new UnityContainer();

     parentContainer
         .RegisterInstance( new AppSettingsHelper(ConfigurationManager.AppSettings))
         .RegisterInstance(RouteTable.Routes)
         .RegisterInstance(HostingEnvironment.VirtualPathProvider)
         .RegisterInstance( " RegisterRoutesHandler " , typeof (MvcRouteHandler));

      foreach (ConnectionStringSettings connectionString in ConfigurationManager.ConnectionStrings)
     {
         parentContainer.RegisterInstance(connectionString.Name, connectionString.ConnectionString);
     }

     parentContainer
         .RegisterType < ISiteService, SiteService > ()
         .RegisterType < IPluginService, PluginService > ()
         .RegisterType < IUserService, UserService > ()
         .RegisterType < ITagService, TagService > ()
         .RegisterType < IPostService, PostService > ()
         .RegisterType < ITrackbackOutboundService, TrackbackOutboundService > ()

..
}

    当然这种做法是有普遍性的，好处也是很明显。就是将来如果业务规则变化时(对应service接口实现类也要发生变化)，这时不需要真正修改已有的代码，只需再开发一个相应的实现类即可满足需求，这种扩展方式也是与设计模式中的思想相符合的。

    说到这里，把话题再深入一下，就是微软模式与实践小组的Service Layer Guidelines中对象这块还会有一个Application Facade（在其Business层中），如下图:

     其完成的是对这些service组件的“应用层面级”封装，说的再白一些，其可以包括对业务工作流，业务实体，业务组件的三者的封装。以便于对外实现（暴露）统一的服务访问接口。就这部分而言，MVCStore做的比Oxiete要好，其在工作流中对各类已定义的服务组件的逻辑调用写的很有味道，比如Commerce.Services项目下的 AcceptPayPalWorkflow.cs 和 ShipOrderWorkflow.cs 。

     当然就目前工作流的作用远不止这些，必定其也可以采用WCF服务的方式把自己暴露给外界。就这一点，其自身也可以转化为一个服务组件，到这里就出现了一个有趣的现象，即：

     已将一些服务组件囊括的工作流自己也成了一个服务组件而被其它服务组件所调用。不是吗？

     在SOA架构中，这种情况是很普遍的，因为组件是一些基本的业务规则逻辑，其应允许被其它组件访问甚至包含以使业务规则更加清晰，说白了就是可复用性。

     对开发者而言只有这样才可能提升开发速度（重用已有组件的好处不仅仅是少写代码，还包括测试和布署等方面的成本也会降低），这一点想一想那些开源的框架就会理解了。而对于企业管理者而言就是保护“已有投资”.

3.两个项目中的困惑

     的确，看了这两个MVC之后，还是有些让我感觉不是太清晰的地方，比如MVCStore中，Commerce.Data项目下的Model/Order.cs类，我刚开始一看，还真被震住了，很有 充血模型 的味，下面是部分代码：

Code

     可正当我带着兴趣去观察其它相应的域模型类时，又回到了贫血域模型。不是吗？的方法是要感觉好像不是一个开发人员写的才会出现这种情况，因为按其架构设计上来看，这个类中被放到Serivce中实现的，因为我不是该项目的开发人员，想不出个所以然来。

     白乎了这些，其它在这两个项目中还有一些差异，当然本文开头提到的那篇文章也说出了一些“问题”。不过还是那句话，没有最好的设计只有最适合的设计，这两个项目都有可圈可点的地方，但对自己所在公司部门是不是“完全适合”只能结合自己团队的情况而定了。

     比如说关于Commerce.MVC.Web中将controller和view放在了一起，就是个问题，比如在团队中有如下分工：

     VIEW开发人员 + Controller开发人员 + Service组件开发

     那么将View目录与Controller目录放在不同的项目中应该是个不错的方式，起码在项目级别上将这两类开发者进行了分离。当然有人会说，一般情况下VIEW 和Controller的设计者应该是一个人而不是两个人, 但分工明确才能尽一步提升生产力，特别是MVC这个框架还很新，有些开发人员学习是从View语法入手，有些人从Controller入手，有些人比如我是从Service入手。这就导致关注和侧重点不同，最后导致自己的理解和优势也会不同。将View分离出来的好处在于发挥各自的优势，让前台开发人员可以将精力放在与UI设计师交流设计实现，界面实现，js（目前是JQuery）封装调用等方面。相信随着项目的不断扩大和开发人员的后续补充势必会造成这样的问题。

好了，今天的内容就先到这里了。

本文转自 daizhenjun 51CTO博客，原文链接：http://blog.51cto.com/daizhj/133249，如需转载请自行联系原作者

微信关注我们

原文链接：https://yq.aliyun.com/articles/416428

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

卍解[为企业部署Windows Server 2008系列一]

Windows server 2008发布至今,已经有了很多成功案例.尤其在金融风暴的冲击下,绿色IT的旗帜下,windows server 2008更是企业节能减排的首选,即可以节约部署运行成本,又大大降低了企业的IT环境管理成本,因为她更容易配置,更容易上手,将微软的优势几乎发挥到了极致.并且在功能和性能上大大增强了,而且大家可以选择性安装,个性定制自己的2008. 那么如何用好2008?如何用她来节省成本?如何定制我们所需要的功能?她出现故障如何排除?性能如何优化? 请听我慢慢道来. 首先我们要熟悉windows server 2008的版本,因为咱们要为企业选择一款经济合适的服务器操作系统版本.以最大化企业利益为己任. 下面咱们来介绍下windows server 2008的操作系统版本: Windows server 2008 web版469美元 Windows server 2008标准版(Standard)999美元（含5个客户端访问许可） Windows server 2008企业版(Enterprise)3999美元（含25个客户端访问许可） Windows se...

2017-11-14

543

面向服务的架构(SOA)和面向服务的集成(SOI)得到了广泛的应用，并且有一种需求变得越来越明显:业务需要集成系统，并允许消费者利用基于标准的方法访问服务。SOA是一种架构范例。在这种架构中，可重用的业务逻辑表现为包含基于标准的、定义良好的接口的服务集，并且可以以松散耦合方式访问它。因为Web Service标准的供应商的支持，以及利用基于这种标准的软件集成不同的系统相对容易，所以在解决企业集成问题方面，SOA得到了普遍的认可。基于Java的中间件和企业应用程序集成(EAI)产品已经被使用了一段时间，现在，许多公司在以不同的方式使用这项技术。虽然一些服务是在Java平台上开发和提供的，但来自基于Java的应用程序的服务消费还有其他灵活的需求。SOAP with Attachments API for Java (SAAJ)通过提供访问服务的标准API来帮助这些服务的消费。有几个基于Java的API可以用来访问服务。这些服务包括SAAJ、基于Java API for XML 的RPC(JAX-RPC)和Web服务调用框架(WSIF)。SAAJ提供了构建服务消费者以及提供者的API。让...

2017-11-14

519

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。