.NET 表示层架构/业务线系统蓝图
我们正在重新审视我们的表示层架构，作为未来新的、重写的业务系统（仅表示层）的蓝图，使用 Microsoft 技术堆栈。
我们拥有大约 30 个 .NET 系统（2、3 和 3.5），其中大约 60% 是基于 Web 的（CWAB + Web Forms），40% 是智能客户端（使用 CAB / SCSF、WinForms） 所有系统都通过 ASMX 或 WCF 集成到后端 SOA 堆栈中（即“后端”系统架构是通用的）。
目标是
- 如果可能的话，尝试使代码库在 Web、Windows 和移动设备之间尽可能保持“通用” （目前在 Web 和 WinForms 之间没有重用 MVP / MVC）
- 将越来越需要支持移动设备
- 我们的大多数系统都是业务系统的重要线 - 功能比美观要求更重要
- 绝对倾向于转向 WPF
- 即使有没有表示层重用，在客户端之间保持一致的架构（MVC / MVP / MVVM 等）
- 保持主流！
摇摆
- 一些想法在ASP.NET MVC 2 + jQuery 等用于 Web + ?Prism / WPF 用于智能客户端之间 与
- Prism for all（智能客户端和 Silverlight） 与
- Sharepoint Web 部件（门户架构） vs
- 离开 Web/Winforms 并等待尘埃落定；）
未来的 HTML5 将如何影响您的思维？
We are revisiting our presentation tier architecture as a blueprint for future new, and re-written business systems (Just the presentation tier), using Microsoft technology stacks.
We have around 30 .NET systems (2, 3, and 3.5), about 60% of which are web-based (CWAB + Web Forms) and 40% Smart Client (using CAB / SCSF, WinForms)
All systems integrate into a back-end SOA stack via ASMX or WCF (i.e. the 'back end' systems architecture is common)
The objectives are
- if possible, try to keep the codebase as 'common' as possible between Web, Windows, and Mobile (currently no reuse of MVP / MVC between Web and WinForms)
- Will increasingly need to support Mobile devices
- Most of our systems are grunt line of business systems - functionality is more important than aesthetic requirements
- Definitely a lean toward moving across to WPF
- Even if there is no presentation tier reuse, to keep a consistent architecture (MVC / MVP / MVVM, etc) between the clients
- Stay mainstream!
Some thoughts have swung between
- ASP.NET MVC 2 + jQuery etc for web + ?Prism / WPF for Smart Client
vs - Prism for all (Smart Client and Silverlight)
vs - Sharepoint Web Parts (Portal Architecture)
vs - Leaving Web / Winforms and waiting for the dust to settle some more ;)
How does the future HTML5 affect your thinking?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们处于类似的情况，并且对这个问题进行了深入的思考。对于我们来说，出于多种原因，我们排除了 Sharepoint Web 部件。对于某些人来说，这可能是一条有效的道路，但价格昂贵。
我们将 MVC 用于面向外部的用户界面，并使用一些 Silverlight 模块来满足需要更丰富的用户交互的特定需求。
对于面向内部的用户界面，我们使用 Silverlight/Prism/MVVM 作为新模块，并且目前使用浏览器控件在现有 WinForms 智能客户端系统中托管新的 Silverlight 模块。我们已经能够在现有智能客户端代码和 Silverlight 模块之间创建所需的交互，但遇到了很多麻烦。这对我们的系统来说效果很好，但您的情况可能会有所不同。我相信我们使用简单的应用程序框架来简化集成，而不是使用更通用但更复杂的智能客户端 CAB 框架。
在未来的某个时刻，当我们将旧模块从 WinForm 升级到 Silverlight 时，会因为不再需要它们而放弃它们，或者重写它们以适应重大的业务变化。然后，我们将重做主机应用程序，完全拥抱 Silverlight/Prism/MVVM 环境并删除所有 WinForm 代码。这种方法的明显优点是我们不必立即重做所有 UI。
到目前为止，它对我们来说运作良好。无论您选择哪种路线，祝您好运。
We are in a similar situation and have given this subject considerable thought. For us we ruled out Sharepoint Web Parts for several reasons. That could be a valid path for some, but expensive.
We are using MVC for externally facing user interfaces with some Silverlight modules for specific needs that require richer user interaction.
For internally facing user interfaces we are using Silverlight/Prism/MVVM for new modules and, for now, hosting the new Silverlight modules in the existing WinForms Smart Client system using a browser control. We have been able to create the needed interaction between the existing Smart Client code and the Silverlight modules with much trouble. This has worked well for our system, but your mileage may vary. I beleive the ease of integration was helped by our simple application framework that we used instead of the more general but more complicated CAB framework for Smart Client.
At some point in the future as we upgrade older modules from WinForm to Silverlight, drop them becasue they are no longer needed, or rewrite them to accomodate significant business changes. We will then redo the host application, completely embrace the Silverlight/Prism/MVVM environment and drop all of the WinForm code. The obvious advantage of this approach being that we do not have to redo all of the UI at once.
So far, it is working well for us. Good luck whatever route you choose.