WCF RIA是否执行不良设计？

Question

过去几周我一直在使用Silverlight涉足WCF RIA,我发现使用它生成设计良好的软件非常困难.我的印象是,它是一种最适合"快速应用程序开发",原型设计和花哨的演示的工具.

举个例子,为了充分利用RIA,我发现你几乎必须从头到尾依赖你的数据模型.WCF RIA的最佳功能(如端到端验证和EF集成)要求您尽可能地呈现实体框架数据模型,一直到您的表示层.这就排除了使用服务层模式,数据映射器或DTO 设计软件的可能性.由于EF的限制,我也发现自己正在努力(迄今无济于事)创建一个具有真正域模型的应用程序.

代码生成的东西很好,我可以看到它节省了我的时间,除了它不支持像多对多关系这样的基本场景.这使得我必须通过暴露中间外键表来通过EF公开我的更多数据库实现细节.

除了这些问题之外,众所周知WCF RIA几乎不可能进行测试.DomainContext类不会隐藏在接口后面,由于更改跟踪和其他细微之处,这样做非常困难.在我看到的每一个案例中,ViewModel最终都直接依赖于DomainContext实现.即使这种依赖是构造函数注入它也没有意义,因为它无法合理地被嘲笑.

所以我想我的问题是双重的:WCF RIA是否强制执行糟糕的设计？如果是这样,有没有合理的解决方法,最终我失去了平台的大部分优势？如果没有,有人能指出一些文献,展示如何使用WCF RIA基于可靠的模式生成优秀的设计吗？

Answer 1

你可能会把这个问题重新说成"我可以吃蛋糕然后吃吗？".

编码了30多年后,我多次看到这个循环: -

• 第三代语言过于灵活,我们正在重复自己做同样的事情.我们需要的是第四代语言或框架,以减少所有这些重复.
• 第四代语言或框架限制太多,迫使我在我的特定项目中找到丑陋的变通方法并"强制执行糟糕的设计".我们需要的是一种更灵活的低级语言,它可以让我们完全按照自己的意愿行事.
• 另一种第三代语言过于灵活......循环重复.

RIA,Lightswitch,WebMatrix等工具已进入第四代阵营.它们通过设计强制执行某些特定的任务来消除重复,并允许开发人员快速完成工作.开发人员以理想的设计交易,以提高开发速度.这种权衡与旧计算本身一样.

所以要回答你的问题,不,你不能吃蛋糕,吃它.您可以按照自己的方式进行操作并使用RIA WCF服务,也可以按照自己的方式进行操作并创建自己的WCF服务.有一些中间地带(一如既往),你可以使用一些RIA WCF然后跳过篮球,让它做你想做的.

顺便说一句,EF确实提供了它最终呈现的模型与您的实际数据库模式之间的大量抽象(尽管付出了很多努力).例如,它允许您在没有中介类的情况下呈现多对多关系.

Answer 2

这个问题的答案是“否”。它不会强制执行“糟糕的设计”。它只是您工具箱中的一个特定工具，旨在解决特定问题。你听起来就像一个人试图拿起锤子来钻孔，然后说：“为什么这个东西不能在我的墙上打出一个好洞呢？” 嗯..因为它是一个锤子人。它是为不同的工作而设计的......

作为开发人员，我们的很多技能都在于找到适合工作的正确工具。Silverlight 和 RIA 有其用途，但它们并不是灵丹妙药。

我认为您在看待这项技术时抱有错误的目标。我是作为一个 TDD、MVC 等的忠实粉丝这样说的。我已经编写了一些使用 DTO、存储库、层、抽象等的应用程序...我还编写了相当多的过去几个月的 Silverlight 和 RIA。

Anthony 说得好：Silverlight 和 RIA 的设计初衷是“消除重复并允许开发人员快速完成工作”。我不认为 Silverlight 和 RIA 是为大型企业应用程序而设计的，其中 VM 中包含大量业务逻辑 - 您需要单元测试和 TDD 来驱动流程...这是不适合这项工作的工具。

我决定在 Silverlight 中查看最近的一些项目中的一些 ViewModel。这是我发现的：我在 VM 中所做的一切几乎都委托给了 Silverlight 已经为我做的事情：数据绑定、观察属性更改、查询数据上下文、保存对数据上下文的更改、验证实体和通知 GUI 等。

Silverlight 和 RIA 已经为我完成了这些任务。我只是委派电话！如果我要编写单元测试，我将测试 Silverlight 和 RIA - 而不是我的领域逻辑！我不需要测试框架 - 我假设 MS 知道他们在做什么。

如果您有足够的复杂性来保证 DTO、数据映射器、服务层等...那么您可能需要考虑 Silverlight 和 RIA 之外的其他东西。知道我在说什么吗？

适合上班族的工具。选择正确的工具。