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

Question

我有一个可在单台 PC 上运行的 WPF 应用程序。我使用 SQL server 数据库，Entity Framework 与数据库通信 和应用程序中的 RDLC 报告。现在，需要使此应用程序在本地公司网络上运行，在该网络中，多个用户（通常最多 25 个左右）将根据角色和权限集访问应用程序。我对此进行了一些研发，主要使用了这里提到的架构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 架构 框架
5. GPC.Entites - 这将包含数据库架构的实体 和额外的部分类

**

客户：

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

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

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

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

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

Answer 1

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

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

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

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

持久性 (EF) -> 域模型 -> 服务层 -> DTO（数据传输对象）-> 客户端

上面提到的 DTO 对象将是一组 POCO（普通旧 C# 对象），它们负责向您的客户端传送数据和从客户端传送数据。您需要这样做，因为由于反向引用和其他封装问题，对域对象进行序列化和淡化将成为问题。放置 DTO 将强制执行上下文边界，这曾经是 SOA 的原则之一——“边界是明确的”，请参阅 this for more info on soa

就客户端而言，您似乎步入正轨。您可能想要做的是重构您当前的客户端应用程序，以便将所有数据查询合并到一个层中。因此，当时机成熟时，您只需将该层替换为服务实现即可。

Answer 2

这很有意义。 （尝试构建 TDD 风格）

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