0

此问题中的 OP 询问有关使用 WCF/OData 作为内部数据访问层的问题。

使用 WCF/OData 作为访问层而不是直接使用 EF/L2S/nHibernate 的论点

响亮的答复似乎是不要这样做。我与 OP 的立场相似，但在最初的问题中没有提出担忧。我正在尝试（本地）为许多不同的平台进行开发，但希望尽可能多地保留数据和业务逻辑服务器端。因此，我将拥有 iOS/Android/Web (MVC)/桌面应用程序。目前，我有一个带有 ORM 数据访问层 (LLBLGen Pro) 的 WinForms 应用程序。

我设想将我的大部分业务/数据访问逻辑（可能仍然使用 LLBLGen 或其他 ORM）移动到 WCF/OData 接口后面。然后让我在不同平台上的所有不同客户端都非常瘦（基本上是 UI 和 WCF 调用）。

这也是过度设计吗？我错过了一个更简单的解决方案吗？

4

2 回答 2

1

I cannot see any problem in your architecture or consider it overengeenered as a OData is a standard protocol and your concept conforms the DRY principle as well.

I change the question: Why would you implement the same business logic in each client to introduce more possible bugs and loose the possibility to fix the errors at one single and centralized place. Your idea makes you able to implement the security layer only once.

OData is a cross-platform standard and you can find a OData libraries for each development platform (MSDN, OData.org, JayData for JavaScript). Furthermore, you can use OData FunctionImports/Service methods and entity-level methods, which will simplify your queries.

于 2013-02-13T09:57:00.970 回答
0

如果您正在运行多平台开发，那么您可能会发现选择与平台无关的通信协议（例如 HTTP）比使用多个驱动程序和 ORM 直接访问您的数据源更实用。此外，由于 OData 是一个 REST 协议，因此您在客户端不需要太多东西：任何可以格式化 OData HTTP 请求和解析 HTTP 响应的东西。不过有几个方面需要注意：

  1. OData 服务器不能替代 SQL 数据库。它支持批处理，但它们与 DB 事务不同（尽管在许多情况下可用于建模事务操作）。它支持父子关系，但不支持经典 SQL 意义上的 JOIN。因此，您必须计划作为 OData 实体公开的内容。使用包装 EF 模型的 WCF 数据服务构建 OData 服务器太容易了。太容易了，因为人们经常公开低级数据库内容而不是构建高级域类型。

  2. 至于今天，OData 多平台客户端仍在开发中，但它们即将到来。如果我可以建议我个人正在研究的东西，请查看 Simple.Data OData 适配器（https://github.com/simplefx/Simple.OData，查看其 Wiki 页面以获取示例） - 它有一个 NuGet 包。虽然这是一个仅支持 .NET 4.0 的客户端库，但它的一部分正在被提取以发布为可移植类库 Simple.OData.Client 以支持 .NET 4.x、Windows Store、Silverlight 5、Windows Phone 8、Android和 iOS。事实上，如果你检查 Git 存储库的 winrt 分支，你会发现已经有一个多平台 PCL，只是还没有在 NuGet 上发布。

于 2013-02-09T09:00:01.170 回答