如何解决客户端 - 服务器应用程序中的无状态问题? [英] How to solve state-stateless in a client-server application?

查看:22
本文介绍了如何解决客户端 - 服务器应用程序中的无状态问题?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我读过一些关于创建无状态网站的书籍,我读过一些关于有状态客户端应用程序的书籍,但是当您必须将两者结合起来时,会出现很多复杂性.我们有一个 Flex 应用程序,它需要通过 .NET 服务将数据保存到数据库中.要记住的事情是:- 并发(乐观/悲观)- 性能:Flex 需要加载大量数据,因此通常需要延迟加载.- 您是否使用 Dto 在服务器和客户端之间传输数据?

I've read some books on creating stateless websites, I've read some about stateful client applications, but a lot of complexity comes along when you have to combine both. We have a Flex application that needs to persist data to a database via .NET services. Things to keep in mind are: - Concurrency (optimistic/pessimistic) - Performance: Flex needs to load in lots of data so lazy-loading is often necessary. - Do you use Dto's to tranfer data between server and client?

我会告诉您我们产品的历史.我们从一开始就使用 SubSonic 作为 o/r 映射器.SubSonic 对象转换为我们编写的 dto,并将这些 dto 传输到客户端.客户端将 dto 转换为域模型.如果客户端需要保存域模型对象,则将其转换回 dto 并发送到服务器.服务器端将 dto 转换为亚音速对象并保存到数据库中.

I'll tell you the history of our product. We've used SubSonic from the beginning as a o/r mapper. SubSonic objects are converted to dto's written by us and these dto's are transferred to the client. Clientside the dto's are converted to the domain model. If clientside a domain model object needs to be saved, it is converted back to a dto and send to the server. Server side the dto is converted to a subsonic object and saved to the database.

现在,前段时间,我们需要 .NET 服务器端的域模型......所以现在我们在服务器端有三个模型,亚音速模型、dto 模型和域模型.dto 模型更简单,更像数据库,领域模型有更多的逻辑.它变得复杂...我们现在必须将 AS3 域模型代码与 C# 域模型代码同步.如果我们可以再做一次(有时间重构),我认为我们不会再使用 dto,而是在客户端和服务器之间传输域模型.问题是这是否现实.Dto 是简单的对象,很容易转移.领域模型对象可能非常复杂.

Now, some time ago, we needed the domain model on the .NET server side... so now we have like three models on the server side, the subsonic model, the dto model and the domain model. The dto model is more simple and resembles the database more, the domain model has much more logic. It gets complex... We now have to synchronize the AS3 domain model code with the C# domain model code. If we could do it again (of get time to refactor) I think we wouldn't use the dto's anymore, but transfer the domain model between client and server. Question is if this is realistic. Dto's are simple objects so easy to transfer. Domain model objects can be very complex.

是否有关于如何为此类应用程序创建架构的书籍?有经验的人写的书?你有这方面的经验吗?

Are there books on how to create an architecture for these kind of applications? Books writte by someone with lots of experience? Do you have experience with this?

推荐答案

实际情况是在客户端和服务器之间共享对象非常复杂.这是您实现它所需的条件:

The reality is that sharing objects between the client and the server is quite complex. Here's what you need to make it happen:

简单/不可扩展的方式:

MarshalByrefObject 继承所有 对象.如果您在服务器上创建对象 A,并将其发送给客户端,则客户端对该对象的任何修改都将自动转发到服务器.

Inherit all of your objects from MarshalByrefObject. If you create Object A on the server, and send it to the client, any client modifications to the object will automatically be forwarded to the server.

虽然这听起来是完美的解决方案,但它有两个主要问题:

While this sounds like the perfect solution, it has two major problems:

  1. 客户端和服务器与 .NET(再见 Web 服务)紧密耦合
  2. 这可能是一场表演噩梦.所有方法/属性访问都将转发到服务器.如果您选择这条路线,那么您的对象应该真正设计为适合大块头的通话,而不是闲聊的通话.

可扩展/困难的方式:

您可以使用 DataContract/Serializable 对象,而不是使用 MarshalByRefObject.然而:

Instead of using MarshalByRefObject, you would use DataContract/Serializable objects. However:

  • 如果您在服务器上创建对象 A,并将其发送给客户端,客户端将收到对象的副本(我们称之为对象 B)
  • 当您将对象 B 发送回服务器时,服务器将收到一个对象 B 的副本(我们称之为对象 C)
  • If you create Object A on the server, and send it to the client, the client will receive a copy of the object (let's call it Object B)
  • When you send Object B back to the server, the server will receive a copy of Object B (let's call it Object C)

但您确实希望服务器将对象 A对象 C 视为相同.不幸的是,CLR 无法做到这一点,因此您需要一个对象合并来同时位于客户端和服务器上.

But you really want the server to treat Object A and Object C as the same. Unfortunately, the CLR cannot do this, so you'll need an Object Merger to sit on both the client and the server.

Object Merger 将包含模型中所有对象的字典,并且知道如何将两个实例标识为相同,并合并来自接收端的任何值.例如,如果客户端在内存中已经有对象 C,并且从服务器接收更新的副本,它将复制这些值.

The Object Merger would contain a dictionary of all objects within the model, and know how to identify two instances as being the same, and merge any values from the receiving end. For instance, if the client already has Object C in memory, and receives an updated copy from the server, it would copy over the values.

不幸的是,这也充满了问题,因为您需要确保正确保留对象引用.您不能盲目地更新对象的所有属性,因为该对象可能具有对其他对象的现有引用,而这些引用又可能需要自己合并.除此之外,您还需要跟踪包含在列表或字典中的添加/删除对象.

Unfortunately, this is also fraught with problems, because you need to ensure that object references are preserved correctly. You can't just blindly update all properties on an object, because the object may have existing references to other objects, which in turn may require their own merging. On top of all this, you would also need to track added/removed objects contained in lists or dictionaries.

我在自己的框架中添加了 n 层支持,所以我现在正在做同样的练习(我正在走可扩展/硬"路线).幸运的是,我有很多支持基础设施来协助识别、合并等.如果您从头开始,这将是一项重要的工作.

I adding n-tier support to my own framework, so I'm going through the same exercise right now (I'm taking the "scalable/hard" route). Fortunately, I have a lot of the supporting infrastructure in-place to assist with identification, merging, etc. If you're starting from scratch, it would be a significant piece of work.

附言将延迟加载代理添加到组合中(我使用的是 Nhibernate),它会变得更多有趣...

P.S. Add lazy-loading proxies into the mix (I'm using Nhibernate), and it gets even more interesting...

这篇关于如何解决客户端 - 服务器应用程序中的无状态问题?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆