将WPF桌面应用程序转换为客户端服务器技术的良好架构

Question

我有一个可在单台PC上运行的WPF应用程序。我用过SQL服务器数据库，实体框架与数据库进行通信 和应用程序中的RDLC报告。现在已经到了使这个应用程序在本地公司网络上运行的要求，其中多个用户（通常大约25个）将根据角色和权限设置访问应用程序。我做了一些R＆amp; D并主要使用了这里提到的架构http://www.codeproject.com/Articles/434282/A-N-Tier-Architecture-Sample-with-ASP-NET-MVC-WCF，在这之后，我做了一个应用程序的纸张设计/架构，看起来像这样

  

在公司网络内的高端服务器上运行的WCF服务

1. GPC.Service本身 - 定义连接到服务的协议 和所有其他必要的信息
2. GPC.Algorithm - 将成为主要的业务逻辑层 包含逻辑，并将是客户端的调用接口 数据库层方法
3. GPC.Persistance - 将有实际的数据库交互方法，如 提取/存储/更新/删除数据库中的记录
4. GPC.Data - 这将包含实体的edmx架构 Framwework
5. GPC.Entites - 这将包含数据库架构的实体 和附加的部分类

**

  

客户：

客户端现在将基于MVVM模式的WPF应用程序（可能将来我们将需要移动到Web应用程序，但现在不需要）。该应用程序的主要组件是：

1. 从Excel导入：目前所有数据都在Excel文件中。这一切 数据需要导入系统。
2. 编辑/更新/删除：导入数据后，允许用户界面 编辑/更新/删除记录
3. 生成重新创建（使用RDLC）
4. 用户/角色管理等。

  

共享：   这是一个包含不同的错误类的库，比如读取excel文件的代码，处理错误，将绑定到UI的集合等。

数据库上下文：将在每个方法的Persistance层内的using语句中创建，以确保不会留下陈旧信息。

这个架构是否遵循n层架构并且是否灵活？这需要哪些改进，请指导我如何改善那些问题。在我继续更改现有应用程序之前，我想确保这是一个很好的架构。

Answer 1

您似乎正走在正确的道路上，但在某些领域可能会过度工程化。

我认为EntityFramework在很大程度上为您处理实体，数据和持久层。除非您希望最终用其他ORM系统替换EntityFramework，否则自己实现它们可能会有点过分。

您正在使用GPC.Services库来避开SOA（面向服务的体系结构）。在这里，您需要了解如何将服务层分解为一个或多个将为客户端应用程序提供服务的atmoic服务。有很多方法可以解决这个问题，主要取决于您计划如何使用服务层。看看RESTful服务，它可以很好地分解服务层，并指导您构建整洁的atmoic服务。请查看Asp.net Web API。

我认为您在GPC.Alogrithms库中寻找的内容实际上是一个域模型。域模型封装了您的所有业务逻辑，并允许您通过公开的公共函数对对象执行状态更改。考虑到这一点，系统的各层将如下所示：

持久性（EF） - ＆gt;域模型 - ＆gt;服务层 - ＆gt; DTO（数据传输对象） - ＆gt;客户端

上面提到的DTO对象是一组POCO（Plain Old C＃Objects），负责向客户端传送数据或从客户端传送数据。您需要这样做，因为由于反向引用和其他封装问题，序列化和脱盐域对象将成为问题。将DTO设置到位将强制执行一个属于SOA的原则的上下文边界 - ＆＃34; Boundarys是明确的＆＃34;，请参阅this for more info on soa

就客户方而言，您似乎正在走上正轨。您可能想要做的是重构当前的客户端应用程序，以便将所有数据查询合并到单个层中。所以到时候你只需用服务实现替换那一层。

Answer 2

这很有道理。 （尝试建立TDD风格）

为了让您的生活更轻松，客户端版本管理考虑使用ClickOnce安装程序在您的用户计算机上强制执行最新版本安装（一旦您将其移动为Web应用程序，这种麻烦就会消失）。