一个MVC框架的原型

2010-12-11T08:27:00Z

基于ASP.NET MVC2和VS2008 SP1，此框架提供以下功能：

为Controller提供Unity的依赖注入
为ActionFilter提供Unity的依赖注入
为Action的方法的参数提供Unity的依赖注入
动态以代码方式定义Action
如果Action直接返回View可以省略Action
使用代码方式为Controller注册ActionInvoker
使用代码方式在Action/Controller/Global三个层次注册ActionFilter
使用代码方式注册Unity组件
使用配置文件方式注册Unity组件
使用代码方式注册路由
使用配置文件方式注册路由（add/remove/ignore），修改配置文件后路由规则直接生效，支持路由到mvc或webform
使用AutoMapper映射Model到ViewModel，提供ActionFilter支持自动映射
提供每个请求开始和结束执行的PerRequestTask
支持同时存在NVelocity和Webform两种视图引擎
NVelocity视图引擎支持各种HtmlHelper扩展方法，支持自定义的扩展方法，支持母板页，支持PartialAction和RenderPartial
演示各种RouteConstraints、ActionFilter、ActionResult、ValueProviderFactory、TempDataPrivider的自定义方式

代码点击这里下载，只是一个原型，仅供参考原理

本文链接

有关网站UI实现的几种方式的讨论

2010-10-13T06:55:00Z

抛砖引玉，提出一些知道的做法，欢迎大家提出更多做法。

对于网站来说，UI最终的形式无非是（X）HTML + 脚本 + 样式，现在的问题是怎么样生成这些前端的元素，在以下几个方面达到平衡：

（假设有开发和前端两种角色，前端负责表现逻辑和表现，而开发负责业务逻辑和业务数据）

1）开发人员的工作量，工作难度

2）前端开发人员（后面省略为前端）的工作量，工作难度

3）产品（假设前端属于产品部）对UI的改动需求能否快速落实（能否只依靠前端实现）

4）服务端的压力（客户端的性能问题暂时不考虑）

（怎么发现自从翻译了《微软应用架构指南》之后，写什么都是翻译的口气了）

第一种方式：XML + XSLT

数据源是XML，由开发人员提供，XSL可以一开始由开发人员写，以后由前端参与开发和维护。

T的过程可以在服务端进行，优点是搜索引擎友好，缺点是服务端压力大。

T的过程也可以在客户端进行，和服务端进行的优缺点互反。

这种方式比较适用访问量大（特别是客户端进行T）、交互简单的系统，比如论坛，因为服务端只需要提供数据源，而XSL则是静态资源可以在客户端缓存。

这种方式的优点是，如果前端直接维护XSL，那么在开发不介入的情况下可以直接对页面布局等进行调整，并且可以做到最好的性能。

而缺点则是，学习成本比较大，如果在客户端进行转换那么搜索引擎支持会不好，而且XSL相对比较难以维护，实现复杂逻辑成本比较大。

第二种方式：ASP.NET Webform

最常见的方式，基于控件，由控件生成HTML，开发也可以直接操作服务端控件。这是一种开发人员主导的方式。

这是一种普适的方式，什么应用都可以支持。缺点是不太利于实现UI快速改动，前端很难参与aspx的维护，因为很多UI都是由控件进行，开发人员很可能在后端操作控件进行一些UI的修改。

第三种方式：纯粹的javascript + 服务端数据源

所有和呈现相关的逻辑，都由javascript来写（可以依赖jquery,jtemplate等组件），以AJAX方式从服务端获取数据进行数据的填充和一些业务逻辑的实现。

这是一种前端主导的方式，会写大量的脚本来实现逻辑，需要的数据从服务端获取。

这种方式比较适合前端互动比较丰富的应用，比如网页游戏。

优点是，前端对页面的布局、行为有很大的自主权，并且服务端的压力也比较小。

缺点是，需要写大量的脚本代码，难度大并且容易出错，并且容易出现安全问题。

第四种方式：模板引擎

模板引擎通过基于HTML的模板加上各种预定义的占位符来实现数据的动态填充。在保证了UI灵活性的同时也保证了非常高的性能。

这种方式对于需要有多界面的新闻系统、博客系统，甚至每一个版块布局都不同的论坛系统来说很适用。

虽然足够灵活，但是前端和开发的配合还是双向的，也就是前端还是需要知道开发提供的数据结构。

并且，对于交互比较复杂的应用来说，可能需要用模板引擎预定义的脚本来写很多逻辑，造成难以维护。

第五种方式：ASP.NET MVC

这同样是一种普适的方式，只不过更适用于面向互联网的网站,而不是面向局域网的内部应用。

虽然MVC已经在UI和UI逻辑方面实现了很好的分离，但是我觉得还是很难在开发没有介入的情况下直接对页面的布局等进行调整。

第六种方式：在服务端为HTML的适当位置动态注入数据

这是一种比较新颖的方式，在服务端加载HTML作为模板文件，然后写代码修改HTML中的dom元素，为元素填充数据。

比如一个a.html配合a.shtml，a.shtml（httphandler）加载a.html然后解析HTML文档，从数据库加在数据填充到HTML中，输出这个HTML。

前端提供的HTML文件可以直接使用，不需要加任何模板标签，不需要加任何控件，所有数据由代码填充进去。

可以像jquery一样支持各种方式来搜索数据的填充路径，也可以把一段html作为模板，循环复制成一个列表页面。

优点是，前端维护HTML/脚本/样式，开发人员写代码生成数据，填充数据，彻底的分离。

缺点是，前端不能改变一些涉及到路径的元素（比如我们通过className来定位元素，前端改变了className就不行），还有性能可能会差一点。

第七种方式：在服务端为HTML动态载入数据，在客户端注入数据

还是以HTML作为模板文件，只不过这个数据组装的过程在客户端进行，相比第六种方式有更好的性能。

也就是服务端不用解析HTML文档，直接为HTML文档中加上一个JSON数据片段，这些数据是这个页面需要的所有数据。

然后，在服务端使用ScriptSharp等框架编译时生成填充数据到HTML的脚本，这个填充过程由客户端执行。

代码还是像第六种方式一样写，但是这段代码会完成两个工作，一个是把部分代码生成脚本文件，第二是把部分代码生成json数据写到页面上。

好像还没看到过有现成的框架是这么干的，难道这种方式不太实用？

其实演变一下的话，也可以是直接写脚本，不用ScriptSharp来生成，但是在服务端写的很大的一个好处是可以直接利用强类型的实体。

想象一下这样的伪代码：Document.FindElement("path").Fill(product.Take(10), product => product.Name);

这样，product这个List的前10项就会以json输出在页面上，而定位元素以及赋值的代码也会以jquery/javascript代码输出在页面上。

优缺点和第六种方式一致。

第八种方式：由服务端生成HTML

这是一种比较极端的方式，所有HTML由代码生成，可以拼字符串也可以利用SharpDom之类的框架。

适合UI随着业务逻辑变化非常大的流程系统，或者一些模板生成工具，不太适合业务系统。

欢迎讨论：

1）您的网站是怎么样的业务并且采用哪种方式？

2）还有什么更好的方式方便前端和开发职责的分离？

本文链接

httpmodule和httphandler配合的又一应用——合并脚本样式

2010-04-01T02:03:00Z

页面上数十个脚本和样式文件怎么去合并又少写人工干预？首先，使用查找替换把所有的

博客园_LoveCherry

一个MVC框架的原型

有关网站UI实现的几种方式的讨论

httpmodule和httphandler配合的又一应用——合并脚本样式