面向业务系统的.NET表示层体系结构/蓝图

Question

我们正在重新审视我们的表示层体系结构，将其作为未来新的、重新编写的业务系统(只是表示层)的蓝图，使用Microsoft技术栈。

我们有大约30个.NET系统(2、3和3.5)，其中大约60%是基于Web的(CWAB + WinForms)和40%的智能客户端(使用CAB / SCSF、WinForms)所有系统都通过ASMX或WCF集成到后端SOA堆栈中(即“后端”系统架构是常见的)。

目标是

如果可能的话，为了使requirements

• Definitely、和Mobile之间的代码库尽可能保持“通用”(目前Web和WinForms之间不重用MVP / MVC )，
• 将越来越需要支持移动设备
• --我们的大多数系统都是业务系统的累加线--功能比美学的WinForms更重要--即使没有表示层重用，功能也更倾向于跨WPF
• ，在客户机之间保持一致的体系结构(MVC / MVP / MVVM等)--

H 111保持主流！H 212F 213

有些想法在两者之间摇摆。

vs

• Sharepoint
• ASP.NET MVC 2+ jQuery等，用于Web +？棱镜/ WPF，用于智能客户端与
• Prism for all (智能客户端和银光) web部件(门户架构)vs
• ，离开Web / Winforms，等待尘埃落定;)

未来的HTML5如何影响你的思维？

为这样一个开放的问题道歉，但会真正珍惜SO社区在这方面的建议和经验！

提前感谢！

Answer 1

我们也有类似的情况，对这个问题作了相当多的思考。对我们来说，由于几个原因，我们排除了Sharepoint Web部件。对一些人来说，这可能是一条有效的道路，但代价高昂。

我们将MVC用于面向外部的用户界面和一些Silverlight模块，以满足需要更丰富的用户交互的特定需求。

对于面向内部的用户界面，我们使用Silverlight/Prism/MVVM作为新模块，目前使用浏览器控件在现有的WinForms智能客户端系统中托管新的Silverlight模块。我们已经能够在现有的智能客户端代码和Silverlight模块之间创建所需的交互。这对我们的系统很有效，但是你的里程可能会有所不同。我相信，我们使用的简单应用程序框架(而不是更通用但更复杂的智能客户端CAB框架)帮助了集成的易用性。

在将来的某个时候，当我们将旧模块从WinForm升级到Silverlight时，放弃它们，因为它们不再需要，或者重写它们以适应重大的业务变化。然后我们将重做主机应用程序，完全接受Silverlight/Prism/MVVM环境，并删除所有的WinForm代码。这种方法的明显优点是我们不必同时重做所有的UI。

到目前为止，它对我们运作良好。祝你好运，不管你选择哪条路。