【问题标题】:Perceived Inefficiencies in Data translation in web ServicesWeb 服务中的数据翻译效率低下
【发布时间】:2010-03-09 18:46:07
【问题描述】:

我已经编写 Web 服务大约一年了,我用来从数据库中获取数据一直显示给用户并再次返回的过程似乎效率低下。

这个问题的目的是确保我遵循最佳实践,而不仅仅是添加额外的工作。

这是数据从数据库到最终用户再返回的路径。

  1. 服务将其从数据库中获取到数据访问层 (DAL) 对象中。
  2. Service 将其转换为 DataContract 以发送给客户端。
  3. 客户端获取 DataContract 并将其转换为客户端对象
  4. 客户端显示对象/用户进行更改/添加对象
  5. Client 将客户端对象转换为 DataContact 并将其发送到 Service
  6. 服务接收 DataContract 并将其转换为数据访问层对象。
  7. 服务使用更改/新对象更新数据库。

如果您一直跟踪对象被转换 4 次 (DAL->Contract->Client Object->Contract->DAL)。当您的应用开始扩展其数据时,这似乎是很多转换。

这是做到这一点的“最佳”方式吗?我错过了什么吗?

以防万一,我使用的是 Visual Studio 2008、WCF、LinqToSQL 和 Windows Mobile 5.0 (NETCF)。

【问题讨论】:

  • 为什么客户端不能直接使用DataContract?
  • @John Saunders:我想可以。 (或者至少使用它的后代)当我开始做 Web 服务时,我被告知如果不这样做会更好。这就是这个问题的目的。需要哪些转换,哪些不需要。
  • 你能添加一些数字吗?一些内存转换不会显着影响您的性能(与从数据库中获取数据并通过网络发送数据有关,甚至可能是 XML 序列化)
  • @Alex:我的错。我可以看到这会让你想到性能问题。我指的是我拥有的从一种类型转换为另一种类型(并返回)的代码量。并且必须创建这么多不同的类来表示相同的数据。

标签: wcf web-services datacontract


【解决方案1】:

如果您减少转换次数(也就是说,如果您将层更紧密地耦合在一起),您可能会忽略会发生什么的问题。

服务可以直接返回一个 DAL 对象。问题是 DAL 对象可能包含关于它们是 DAL 对象这一事实的数据,而不是关于它们携带的数据的数据。例如,LINQ to SQL 类派生自包含 LINQ to SQL 功能的基类 - 客户端不需要此基类数据,也不应发送。

客户端可以直接使用服务器发回的 DAL 对象。但这要求客户端和服务器使用相同的平台——例如.NET。他们还必须使用兼容版本的 .NET,以便客户端可以使用服务器端 DAL 对象。

客户端现在可以显示它喜欢的 DAL 对象,假设它不需要像 INotifyPropertyChanged 这样的客户端接口,服务器不需要运行这样的代码,但客户端可能需要它来进行数据绑定和验证.

请注意,每一层都有自己的需求。通过保持这些需求独立,代码更易于设计和维护。是的,您必须复制一些数据,但与维护必须同时执行四项不同操作的代码的成本相比,这很便宜。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2015-10-16
    • 2012-03-17
    • 1970-01-01
    • 1970-01-01
    • 2016-02-25
    • 2016-12-04
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多