我读过一些有关创建无状态网站的书籍，也读过一些有关有状态客户端应用程序的书籍，但是当您必须将两者结合起来时，就会出现很多复杂性。我们有一个 Flex 应用程序，需要通过 .NET 服务将数据保存到数据库中。需要记住的事情是：
- 并发（乐观/悲观）
- 性能：Flex 需要加载大量数据，因此通常需要延迟加载。
- 您是否使用 Dto 在服务器和客户端之间传输数据？
我将告诉您我们产品的历史。我们从一开始就使用 SubSonic 作为 o/r 映射器。 SubSonic 对象被转换为我们编写的 dto，并将这些 dto 传输到客户端。客户端将 dto 转换为域模型。如果客户端需要保存域模型对象，则会将其转换回 dto 并发送到服务器。服务器端 dto 被转换为亚音速对象并保存到数据库中。
现在，不久前，我们需要 .NET 服务器端的域模型...所以现在我们在服务器端有三个模型：亚音速模型、dto 模型和域模型。 dto 模型更简单，更类似于数据库，领域模型有更多逻辑。它变得复杂...我们现在必须将 AS3 域模型代码与 C# 域模型代码同步。如果我们可以再做一次（有时间重构），我想我们不会再使用 dto，而是在客户端和服务器之间传输域模型。问题是这是否现实。 Dto 是简单的对象，因此很容易传输。领域模型对象可能非常复杂。
是否有关于如何为此类应用程序创建架构的书籍？由经验丰富的人写的书？你有这方面的经验吗？
事实上，在客户端和服务器之间共享对象是相当复杂的。要实现这一目标，您需要满足以下条件：
简单/不可扩展的方法：
Inherit all您的对象来自MarshalByrefObject。如果您在服务器上创建对象 A 并将其发送到客户端，则客户端对该对象的任何修改都将自动转发到服务器。
虽然这听起来像是完美的解决方案，但它有两个主要问题：
- 客户端和服务器与 .NET 紧密耦合（再见 Web 服务）
- 这可能是一场性能噩梦。所有方法/属性访问都将转发到服务器。如果您选择这条路线，您的对象实际上应该是为粗调用而不是闲聊而设计的。
可扩展/困难的方式：
而不是使用MarshalByRefObject，你会使用DataContract/Serializable对象。然而：
- 如果你创建Object A在服务器上，并将其发送到客户端，
客户将收到copy对象的（我们称其为Object B)
- 当你寄出Object B返回到服务器，服务器会收到一个copy对象 B（我们称其为Object C)
但你确实希望服务器能够处理Object A and Object C一样。不幸的是，CLR 无法做到这一点，因此您需要一个对象合并坐在客户端和服务器上。
The 对象合并将包含模型中所有对象的字典，并且知道如何将两个实例识别为相同的，并合并来自接收端的任何值。例如，如果客户端内存中已经有对象 C，并且从服务器接收到更新的副本，它将复制这些值。
不幸的是，这也充满了问题，因为您需要确保正确保留对象引用。您不能盲目地更新对象上的所有属性，因为该对象可能具有对其他对象的现有引用，而这些引用又可能需要它们自己的合并。除此之外，您还需要跟踪列表或字典中包含的添加/删除的对象。
我向自己的框架添加了 n 层支持，因此我现在正在进行相同的练习（我正在采取“可扩展/硬”路线）。幸运的是，我有很多支持基础设施来协助识别、合并等。如果您从头开始，这将是一项重要的工作。
附：添加延迟加载代理到混合中（我正在使用 Nhibernate），它会变得均匀more有趣的...
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
