可能的架构陷阱

Question

我目前正在构建一个相当复杂的CRM / POS系统，它具有以下要求：

1. 系统需要能够安装在一台机器（PC）上
2. 系统需要能够安装在可作为服务器的1台计算机上，并可由多台客户端计算机（本地网络，有线和无线）访问
3. 系统需要能够在没有互联网连接的情况下运行

系统启动后，下一阶段将是创建基于Web的版本。用户界面是最重要的，需要尽可能光滑，因为它是一个非常注重图像的行业。

我已经确定的架构如下：

• Sql Server 2008 Express DB
• Linq-To-Sql数据层
• 暴露linq数据层的WCF服务
• 前端的WPF

这应该支持所有3个要求，我希望为基于Web的第2阶段提供从WPF到Silverlight的相当简单的端口。

我的问题是，我选择的架构有什么问题吗？我广泛使用asp.net和Windows Forms但是在WPF方面没什么经验（选择它用于图形功能）。通过WCF在WPF中绑定Linq-To-Sql是否有任何问题？

Answer 1

一些想法：

如果您计划从WPF到Silverlight的端口，我建议您遵循像MVVM这样的分离演示模式。根据UI的复杂性，遵循PRISM指南和多目标，您的WPF和SL开发可能会为您节省一些时间。或者，您可能会考虑完全放弃WPF并从一开始就开发一个浏览器外的SL应用程序 - 两个XAML方言和工具包越来越近了。但是，这可能会使“断开连接”的情况复杂化。

请记住，您的服务设计（低干扰和最小数据传输）将成为基于网络的版本成功的一个因素。

Answer 2

由于您以后需要基于Web的解决方案，为什么不在单台PC上安装IIS，以便您的单机解决方案也是“基于Web的”。

然后，您可以从第一天开始使用Silverlight。 但是，您是否需要在单一PC系统的UI中执行任何无法通过Silverlight执行的操作？

您是否希望快速获得Single PC版本，然后将移植到Web部署解决方案的痛苦，或者您是否想要一开始的痛苦？

Answer 3

我最近对此进行了研究并得出结论，实体框架在数据库和WCF / WPF之间更好地配合。文章The Entity Framework In Layered Architectures在我的决策过程中非常重要。最初采用数据库不可知方法也可能更好。

现在已经构建了大部分应用程序（DB-＆gt; EF-＆gt; WPF桌面应用程序），我仍然很高兴我选择了EF。 EF为我做了大部分繁重的工作，我认为它在关系和面向对象之间进行了很好的映射。

如果您打算使用silverlight发布网络版，那么我会注意advice，首先将两个版本构建为您的架构的一部分。回顾性地很难做到这一点。请参阅Code reuse in WPF and Silverlight 2。

在任何一种情况下，我都要先进行所有要求的验证。构建一个简单的概念验证应用程序，验证您所选择的体系结构可以满足您的所有三个要求。