我是 .Net RIA Services 的新手，但我认为，它的本质是针对 Microsoft 通常关心的 RAD。但是，这不是在表示和应用程序/业务逻辑之间引入了更多的耦合吗？这项新技术如何帮助越来越多对 OOAD 最佳实践和 SOLID、GRASP 和设计模式等概念感兴趣的开发人员？或者有办法实现这两个目标？！
问问题
223 次
3 回答
1
我怀疑此类技术的作者是否试图增加对此类设计原则的兴趣。我们所能期望的最好的结果是，像这样的框架可能会导致符合最佳实践的开发。
您关于表示和业务逻辑之间的耦合以及 RIA 是否会增加它的问题很有趣。
我们确实需要非常仔细地定义耦合。如果业务逻辑发生变化，表示逻辑的哪些细节必须改变？表现形式的哪些变化需要业务逻辑的变化。
在某种程度上，任何表示层，无论是否是 RIA，都必须随着业务语义的变化而变化。所以有些耦合是不可避免的。然而，精心设计的业务逻辑往往会支持许多不同的演示文稿，但我怀疑复杂的 RIA 应用程序往往会对业务逻辑提出更高的要求。
所以我的猜测是，.Net RIA 将做它需要做的事情，以提供我们希望看到的最终用户体验。我不相信它会强制进行不必要的耦合。您是否有一些您认为导致过度耦合的特殊示例？
于 2009-08-16T09:43:45.910 回答
1
它与开发人员在业务层和表示层之间共享的内容有很大关系。RIA 服务确实使您可以轻松地让您的表示层访问您的实体框架类，这显然会导致耦合。
对于有耦合问题的开发人员（应该是每个人），定义业务层和表示层之间的通信模型也很容易。RIA 服务的服务器端（我认为它是业务层的一部分，因为它只是一个 Web 服务）知道如何从您的业务对象构建模型。Silverlight 只需要知道如何使用模型并呈现它。这对我来说看起来不像是耦合。
于 2009-10-12T10:56:53.710 回答
0
在过去的几天里，我一直在思考类似的想法......我不完全确定这是否会让开发人员保留解耦方法......证明或反驳这一点的示例不过会很棒！
于 2009-09-08T14:06:21.850 回答