刚看完了Implement MVC with ASP.NET那一章。这里的controller仍然是依赖于ASP.NET的： public class Solution : System.Web.UI.Page而且Solution类的方法也紧密地与特定的ASP.NET页面耦合在一起（譬如SubmitBtn_Click方法，desktop-based application会如何调用这样一个方法？console-based application呢？），我更愿意把它看作view的一个组成部分，而不是一个controller——它只不过是把页面上的一些代码搬到.cs文件里，让页面看上去干净一些。就象Struts的ActionForm、Tapestry的Page Class，它更应该属于view的一种实现方式。所以我最初的问题仍然没有解决：如果业务操作由如此厚重的view（或者按照MS的说法，把它叫做controller吧，但它毕竟是与ASP.NET紧密耦合的）来完成，当你想为这个web application提供另一种view（例如XSLT-view，甚至干脆就是desktop client），如何能够避免重复这些业务代码？更何况类似于Solution类的code-behind class看起来是要直接控制工作流的。请lins（以及其他的高手）指教。
为你的应用建一个类，把具体的操作写到里面，它是位于DAL之上的，在ASPX.CS中调用该类的方法。
to gOODiDEA(无语)： 或者说，建立一个位于Data Access层与Presentation层之间的Business Service层，是这样吧？在这一层上，MS有没有什么标准或者推荐的做法？
我已经down了ESP，请问那几个经典例子在哪里可以找到？
public class Solution : System.Web.UI.Page而且Solution类的方法也紧密地与特定的ASP.NET页面耦合在一起（譬如SubmitBtn_Click方法，desktop-based application会如何调用这样一个方法？console-based application呢？），我更愿意把它看作view的一个组成部分，而不是一个controller——它只不过是把页面上的一些代码搬到.cs文件里，让页面看上去干净一些。就象Struts的ActionForm、Tapestry的Page Class，它更应该属于view的一种实现方式。所以我最初的问题仍然没有解决：如果业务操作由如此厚重的view（或者按照MS的说法，把它叫做controller吧，但它毕竟是与ASP.NET紧密耦合的）来完成，当你想为这个web application提供另一种view（例如XSLT-view，甚至干脆就是desktop client），如何能够避免重复这些业务代码？更何况类似于Solution类的code-behind class看起来是要直接控制工作流的。请lins（以及其他的高手）指教。
或者说，建立一个位于Data Access层与Presentation层之间的Business Service层，是这样吧？在这一层上，MS有没有什么标准或者推荐的做法？
请各位高人指教！