zoukankan      html  css  js  c++  java
  • 【转载】基于ASP.NET MVC 3的企业应用项目总结

    http://www.cnblogs.com/qiuliang/archive/2011/08/27/2155301.html

     为期三个月的开发加测试工作终于告一段落了,这是我们团队第一次采用ASP.NET MVC(直接使用最新的MVC 3)开发企业应用,期间碰到了很多问题,但在大家的努力下,也都一一解决,先简单介绍一下项目情况吧,是公司的一套业务运营系统,总的从技术实现难度来讲,没有什么特殊的地方,只有相关部分的业务逻辑算法比较复杂。项目开始前,最大的风险在于整个team除了另外一名同事和我使用过MVC,其他人都是第一次使用,并且另外那名同事在项目开始一个月左右离职了~~!好在通过大量的交流沟通、code review、内测等手段下,项目基本成功完成。

    一、技术架构介绍

      基于.Net的多层解决方案,web框架采用了微软的ASP.NET MVC 3(视图引擎为Razor),数据层采用Entity Framework 4.0。界面组件方面使用了Telerik for MVC版本,JS框架依然是强大的JQuery。系统提供了中、英两套语言版本,采用微软官方推荐的多语言解决方案,该方案很容易扩展其他语言版本。

    二、MVC

      个人感觉ASP.NET MVC 3相比2和1,并没有带来革命性的变化,但一些小的改进还是相当不错的,也提高了不少开发人员的效率。
    以下列表显示了我们用到的一些ASP.NET MVC的特性(包括ASP.NET MVC 3但不限于3)
    1. 基于layout的页面结构,一个首页可以拆分成如下:包含title、head、body、以及公用JS、CSS文件的最顶层layout。包含菜单导航的分部视图(Partial View)包含主页面内容的View。主页面里又可以包含其他公共的分部视图,或为了层次更清晰而人为拆分的逻辑部分视图(设计合理的部分视图有利于提高代码层次的清晰程度,但过多的使用也会降低系统性能,毕竟多了一些IO操作)。
    2. 通过使用ViewResult、ActionResult、PartialResult、JsonResult输出不同的内容。
    3. 新增了Dynamic特性,配合Razor可以很方便的在视图上使用控制器提供的数据。
    4. MVC Chart组件可以很方便的输出比较专业的图表。
    5. 控制器基类提供了很多重写方法,可以较为方便的进行一些全局的处理,例如:异常、方法级别的注入等。
    6. unobtrusive js,通过服务器端ModelMetadata和客户端的unobtrusive js,可以做到前后台的统一验证,大大减少开发量。

    三、Razor

      采用了微软最新的Razor(模板引擎语言)配合MVC3进行开发,新一代的视图引擎Razor以简洁的“@”开头的写法,对强类型的智能感知做的也非常不错(不过在JavaScript代码部分的智能感知还是有些问题)。相比ASPX视图引擎,Razor还是胜在简洁上,也有第三方的NVelocity模板引擎,虽然语法也很简洁,但智能感知方面就做的比较差了,因此,开发ASP.NET MVC 3,Razor还是首选。至于性能上的比较,没有实际分析过,可能会比ASPX略逊一些。
    总结Razor的优点如下:
    1. 代码流畅简洁。
    2. 与HTML结合很顺畅,不需要单独处理大括号。
    3. 代码高亮显示。
    4. 很方便的输出单行文本(@:)或多行文本()。

    四、Entity Framework

      数据层采用微软提供的ORM框架Entity Framework,并配合Linq To Entity,能够以简洁的linq语句或lambda表达式,来代替复杂冗长的SQL语句。总体上来讲EF相比Linq To SQL,并没有特别大的不同,其中结合Validation类来对Model进行MetadataType的标记,来实现数据的校验,感觉是一个比较不错的方式。更能体现代码单一职责原则,我们不必要在控制器里写大量的校验逻辑。
      EF的edmx文件在从数据库更新的时候,容易出现更新不成功的情况,这时候则需要将实体删除并从数据库新增就可以解决这个问题。对于EF的DBContext,在不同层传递的时候,应该尽量一致,个人更倾向于实例化对象的方式,而且比较好的实践方式是:在业务层持有一个全局的数据层对象引用,在控制器里使用实例化的业务层对象对数据库进行读写操作。在项目的前期,因为大量使用了数据层或业务层的静态方法,以至于在业务逻辑相对简单的系统管理模块出现了大量的bug,主要的原因就是数据上下文使用混乱,前后不一致,应该说是我们的一个教训。需要谨慎处理延迟加载,以降低性能方面的影响。什么时候需要延迟加载、什么时候不需要延迟加载,感觉还是跟具体的业务逻辑有关,不能一概而论。数据对象的使用也是要考虑的一方面,尤其是在前台更改了某些数据属性之后,在同一个上下文里进行数据保存操作后,可能会出现你所不期望的修改。尤其是在复杂的业务计算类库上面,一个对象经过重重传递,很容易出这个问题,并且不太好查。

    总结:要明确的知道数据对象的使用范围。

    五、AOP

      对于ASP.NET MVC 3来讲,天生就是支持AOP的,框架自带的ActionFilterAttribute基类提供了四个重载方法,
    如下所示:
    1. public virtual void OnActionExecuted(ActionExecutedContext filterContext) 该方法在Action执行之后触发。
    2. public virtual void OnActionExecuting(ActionExecutingContext filterContext) 该方法在Action执行之前触发。
    3. public virtual void OnResultExecuted(ResultExecutedContext filterContext) 该方法在Result渲染完之后触发。
    4. public virtual void OnResultExecuting(ResultExecutingContext filterContext) 该方法在Result渲染之前触发。

    通过这四个重载方法,可以非常方便的将代码逻辑织入到Action的生命周期内。对于我们这个系统,实现了如下几个方面的织入:
    1. 功能权限控制。
    2. 数据权限控制。
    3. 项目状态检查。
    4. 操作日志。

    AOP带来的好处也是显而易见的,减少代码量、降低业务逻辑和非业务逻辑代码的耦合度、便于维护。

    六、Telerik

      为了提高开发效率和复用代码,在界面上也大量的使用了Telerik控件for ASP.NET MVC版本。
    主要有如下应用:
    DatePicker,日期选择组件,其中可以设置可以选取的范围是亮点,但其本身绑定的一些事件也是有利有弊(例如Onblur之后的自动设置日期值),客户端不能灵活的控制。
    Window,仿模态窗口,弹窗利器。
    Grid,表格组件,功能很强大,但有些特殊场景还是很别扭。同样是客户端控制程度不够。
    TreeView,树组件,功能也很强大,很好用。

    总结:有一套好的可复用组件确实能大大提高开发效率,但前提是要对其有较好的把控能力,否则容易适得其反。

    七、多语言解决方案

      采用微软官方推荐的资源文件做法,我们这个系统有中、英文两个版本,则在所有的显示字段、交互提示等地方,全部使用了资源文件标签。其原理就是根据用户选择的语言种类(存到cookie),动态设置当前线程的语言环境,剩下的事情微软已经帮我们做好了,实现起来很简单,推荐使用。

    关键代码:

    HttpCookie hk = Utils.Language.GetLangCookie(); 
    string langName = ""
    if (hk != null
    langName = hk.Value; 
    else 
    { langName = "zh-cn"; } 
    CultureInfo cultureInfo = new System.Globalization.CultureInfo(langName);<BR>System.Threading.Thread.CurrentThread.CurrentUICulture = cultureInfo; <BR>System.Threading.Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(cultureInfo.Name);

    八、其他:log4net、NPOI

      同时也采用了一些其他优秀的开源框架:使用log4net来记录异常日志和一些操作日志,使用npoi来进行excel操作。这两个框架都是从JAVA平台移植过来,不得不说,JAVA社区在开源框架方面的研究要胜于.Net。

    九、未来考虑

      引入Ioc框架:为了降低业务层与数据层、控制器之间的耦合,使代码更灵活以及更容易扩展和维护,考虑后续引入IOC框架(例如:unity、spring.net、castle windsor等)
      采用独立缓存服务器:一直以来,缓存都是提升系统性能最廉价的解决方案,目前我们需要缓存的数据量较小,直接使用.Net自带缓存进行缓存处理,例如:组织机构、功能菜单等,虽然.NET自带的缓存功能很强大,但毕竟和app server共用内存,且处于同一应用程序域内,如果在缓存使用较多的情况下,性能不是很理想。未来考虑使用分布式缓存,例如:memcache、redis等优秀的第三方缓存框架。
      更好的用户体验,主要体现在优化部分操作流程和页面操作体验。
      WCF重构部分服务以支撑更多不同类型的客户端。

  • 相关阅读:
    仿照Excel的控件,支持c#
    Excel地图插件
    com接口调用
    决策树算法
    python练习题
    numpy练习题
    机器学习_线性回归
    python学习之老男孩python全栈第九期_数据库day005知识点总结 —— MySQL数据库day5
    problem-solving-with-algorithms-and-data-structure-usingpython(使用python解决算法和数据结构) -- 基本数据结构 -- 队列
    python学习之老男孩python全栈第九期_数据库day004知识点总结 —— MySQL数据库day4
  • 原文地址:https://www.cnblogs.com/fx2008/p/2436276.html
Copyright © 2011-2022 走看看