WCF RIA 是否强制实施不良设计？
过去几周我一直在尝试使用 Silverlight 进行 WCF RIA，我发现使用它生成设计良好的软件非常困难。我的印象是，它是最适合用于“快速应用程序开发”、原型设计和精美演示的工具。
举个例子，为了充分利用 RIA，我发现您几乎必须从头到尾都依赖于您的数据模型。 WCF RIA 的最佳功能（例如端到端验证和 EF 集成）要求您几乎按原样呈现实体框架数据模型，一直深入到表示层。这妨碍了使用服务层模式、数据映射器或DTO来设计软件。由于 EF 的限制，我还发现自己在努力创建具有真正的 域模型 的应用程序（到目前为止无济于事） 。
代码生成功能很好，我可以看到它节省了我的时间，只是它不支持多对多关系等基本场景。这导致我必须通过 EF 公开中间外键表来公开更多数据库实现细节。
除了这些问题之外，众所周知，WCF RIA 几乎无法测试。 DomainContext 类没有隐藏在接口后面，并且由于更改跟踪和其他微妙之处，这样做非常困难。在我在野外看到的每一个案例中，ViewModel 最终都会直接依赖于 DomainContext 实现。即使此依赖项是构造函数注入的，它也是毫无意义的，因为它无法合理地被模拟。
所以我想我的问题有两个：WCF RIA 是否会强制实施不良设计？如果是这样，是否有任何合理的解决方法，不会让我失去该平台的大部分优势？如果没有，有人可以向我指出一些文献，展示如何使用 WCF RIA 基于经过验证的模式生成良好的设计吗？
I have been dabbling in WCF RIA with Silverlight for the past few weeks and I am finding it very difficult to generate well-designed software using it. My impression is that it's a tool that's best used for "rapid application development", prototyping and fancy-looking demonstrations.
As an example, to make the most of RIA I find you pretty much have to take a dependency on your data model from end to end. The best-sounding features of WCF RIA (like end-to-end validation and EF integration) require you to present your Entity Framework data model pretty much as-is, all the way down into your presentation layer. This precludes designing your software using a Service Layer pattern, data mappers or DTO's. I also find myself struggling (so far to no avail) to create an application with a true Domain Model due to limitations in EF.
The code generation stuff is nice and I could see it saving me time, except that it doesn't support such basic scenarios as many-to-many relationships. This causes me to have to expose even more of my database implementation details through EF by exposing the intermediate foreign key table.
On top of these issues, WCF RIA is notoriously almost impossible to test. DomainContext classes are not hidden behind interfaces and doing so is extremely difficult due to change tracking and other subtleties. In every single case I have seen in the wild, ViewModels end up taking direct dependencies on the DomainContext implementation. Even when this dependency is constructor-injected it's meaningless because it can't reasonably be mocked.
So I guess my question is two-fold: Does WCF RIA enforce bad design? If so, are there any reasonable workarounds that don't end up with me losing most of the advantages of the platform? And if not, can someone point me to some literature that shows how to generate good designs based on tried-and-true patterns using WCF RIA?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以将问题重新表述为“我可以鱼与熊掌兼得吗？”。
我已经编码了大约 30 多年，我已经多次看到这个循环：-
RIA、Lightswitch、WebMatrix 等工具属于第四代阵营。它们在设计上强制采用特定的方式来执行某些任务，以消除重复并允许开发人员快速完成工作。开发人员用理想的设计来换取开发速度。这种权衡就像旧的计算本身一样。
所以回答你的问题，不，你不能鱼与熊掌兼得。您可以按照他们的方式做事并使用 RIA WCF 服务，或者按照您的方式做事并创建您自己的
WCF 服务。有一些中间立场（一如既往），您可以使用一些 RIA WCF，然后跳过圈子让它做您想要的事情。
顺便说一句，EF 确实在它最终呈现的模型和实际数据库架构之间提供了相当多的抽象（尽管付出了很大的努力）。例如，它确实允许您在没有中介类的情况下呈现多对多关系。
You might re-phrase the question as "Can I have my cake and eat it?".
Having been coding for some 30+ years I have seen this cycle many times:-
Tools such as RIA, Lightswitch, WebMatrix etc are in the 4th Generation camp. They by design enforce a specific way to doing certain tasks in order to eliminate repeation and to allow developers bang out working stuff quickly. Developers trade ideal design for speed of developement. This tradeoff is as old computing itself.
So to answer your question, no you can't have your cake and eat it. You either do things their way and use the RIA WCF service or you do things your way and create your own
WCF services. There is some middle ground (as always) where you can use some RIA WCF then jump through hoops making it do what you want.
BTW, EF does offer considerable abstraction (albeit with a lot effort) between the model it ends up presenting and your actual Database schema. It does for example allow you to present a many-to-many relationship without an intermediatory class.
这个问题的答案是“否”。它不会强制执行“糟糕的设计”。它只是您工具箱中的一个特定工具，旨在解决特定问题。你听起来就像一个人试图拿起锤子来钻孔，然后说：“为什么这个东西不能在我的墙上打出一个好洞呢？”嗯..因为它是一个锤子人。它是为不同的工作而设计的……
作为开发人员，我们的很多技能都在于找出适合该工作的正确工具。 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 之外的其他东西。知道我在说什么吗？
适合上班族的工具。选择正确的工具。
The answer to this question is "No". It doesn't enforce "bad design". It's just a specific tool in your toolbox and it's designed to solve a particular problem. You sound like someone who is trying to take a hammer and use it to drill a hole, and saying, "Why doesn't this thing make a nice hole in my wall?" Ummm.. Because it's a hammer man. It's designed for a different job...
A lot of our skills as developers is in figuring out the right tool to use for the job. Silverlight and RIA have their uses, but they are not a magic silver bullet.
I think you're looking at the technology with the wrong goals in mind. And I say this as a guy who is a big fan of TDD, MVC, etc. I've written my share of apps that use DTO's, Repositories, layers, abstractions, etc... I've also written quite a bit of Silverlight and RIA in the past few months.
Anthony said it well: Silverlight and RIA are designed to "eliminate repeation and to allow developers bang out working stuff quickly." I don't think Silverlight and RIA are desgined for giant enterprise apps with loads of business logic tucked into the VM - something where you need unit testing and TDD to drive the process... This is the wrong tool for THAT job.
I decided to look at some of my ViewModels in some recent projects in Silverlight. Here's what I found: Everything I'm doing in the VM is pretty much delegating to something Silverlight already does for me: databinding, observing property changes, querying data contexts, saving changes to a data context, validating entities and notifying the GUI, etc.
Silverlight and RIA already do these tasks for me. I am just delegating calls! If I were to write a unit test, I'd be testing Silverlight and RIA - not my domain logic! I don't need to test the framework - I assume MS knows what they're doing.
If you have enough complexity to warrant DTO's, data mappers, service layers, etc... Then you probably need to think about something other than Silverlight and RIA. Know what I'm saying?
The right tool for the job man. Choose the right tools.