使用 POCO 对象或分离的 EntityFramework 对象通过 WCF 公开数据库更好吗？

Question

我创建了一个WCF service 负责公开我的数据库数据，因为我不希望我的应用程序直接访问数据库（出于安全原因），并且我需要能够与第三方应用程序共享数据.

我的解决方案是这样构造的：WPF application -> WCFService library -> DataAccessLayer library。 （箭头定义程序集依赖'取决于'）

为了实现WCF service，我考虑过从服务中简单地返回detached EntityFramework objects，但它会强制主应用程序依赖DataAccessLayer 库。

我可以解决的唯一方法是生成 POCO objects 并使用它们通过网络发送它们，但现在我必须来回映射值 EntityFramework.

目前我正在通过T4 template 动态生成POCOs，并且我正在使用AutoMapper 来回映射值EntityFramework。

Wcf 服务只需实现存储库模式即可公开数据。

这是一个好的解决方案吗？还有其他选择吗？ 有什么缺点需要注意吗？

Answer 1

根据您的限制，我必须同意这个解决方案。

我创建了一个几乎相同的解决方案，尽管我们的动机略有不同。我们的客户端是Delphi Win32，当时对JSON没有很好的支持，所以只好用SOAP。

客户端也不支持可为空的原语，因此 POCO 删除了所有不支持的类型，并执行了其他更改以确保互操作性，然后我们使用 Automapper 自定义映射来处理双向转换。

所有 WCF 服务（合同和实现）也由 T4 模板使用通用存储库生成。使用 T4 模板，我能够为每个表生成单独的 WCF 服务用于 CRUD 操作，然后手动创建特定于业务的 WCF 服务。

最后，我还能够使用 T4 模板生成与 SOAP 服务交互的 Delphi 存储库。

或者

您可以轻松地将 POCO（和代码生成）移至单独的项目，更改 DataAccessLayer 库以引用 POCO 库，并且仅包含由 POCO 的 DbSet 和数据访问逻辑组成的 Db 上下文，但不包含实体（现在是 POCO）。您的客户不需要依赖 DataAccessLayer 库。

所以...一个很好的解决方案，取决于您的限制。