如何在WPF和ASP.NET MVC应用程序之间共享最多的代码? [英] How to share the most code between a WPF and an ASP.NET MVC application?

问题描述

我可以使用什么体系结构和模式在WPF和ASP.NET MVC应用程序之间共享最多的模型和逻辑代码?

What architecture and patterns can I use to share the most model and logic code between a WPF and an ASP.NET MVC application?

除了将我的数据实体与两个演示项目分开之外，我在这里还试图实现更多目标.还有很多共同点，例如我希望在共享代码中保留的用户界面逻辑在什么条件下显示，什么时候需要显示，等等.

I am trying to achieve a bit more here than just separating my data entities from the two presentation projects. There is a lot more in common e.g. UI logic on what gets displayed under what conditions, when is something required, etc. that I would like to keep in the shared code.

已添加:我才刚刚开始真正喜欢视图模型的概念，而与实体模型无关.尽管其中使用的某些注释位于特定于MVC的程序集中，但提供的元数据实际上都不是特定于Web的.我非常想探索使用我的MVC视图模型作为绑定到WPF视图的数据源.在这方面的任何建议将不胜感激.

ADDED: I am just beginning to really like the concept of view models independent of my entity model driving my presentation. While some of the annotations used in these are located in assemblies specific to MVC, none of the metadata provided is actually web specific. I would very much like to explore using my MVC view models as data sources for binding to WPF views. Any suggestions on this front will be most appreciated.

推荐答案

我个人最喜欢的配置类似于上面的Adam King建议的配置，但是我希望将逻辑DLL保留为Web项目的一部分.我运行了一个遵循此模式的名为 CT终端的项目.我的Terminal.Domain项目包含所有应用程序逻辑，并仅返回一个CommandResult对象，该对象的属性充当指示UI项目该做什么的指令.用户界面完全笨拙，仅处理Domain项目告诉用户的内容.

My personal favorite configuration is similar to the one Adam King suggested above but I like to keep the logic DLL as part of the web project. I run a project called CT Terminal that follows this pattern. My Terminal.Domain project contains all the application logic and simply returns a CommandResult object with properties that act as instructions to tell the UI project what to do. The UI is completely dumb and only processes what it's told to by the Domain project.

现在，按照亚当·金(Adam King)的方法，然后将Domain DLL打入WPF应用程序，然后对UI进行编码，以遵循返回的CommandResult对象中的指令.但是，我更喜欢另一种方法.我编写了MVC 3 UI，以公开JSON API.任何应用程序都可以使用此API. JSON API很简单，因为它基本上是我Terminal.Domain项目CommandResult对象的包装.返回的JSON具有相同的基本属性.这样，我将编写WPF应用程序以使用此API而不是DLL.现在，如果我对内部应用程序逻辑进行了较小的更改，则只需将Web项目部署到实时服务器即可.所有使用该API的客户端都会自动获得此新逻辑.

Now, following Adam King's approach I would then slap that Domain DLL into a WPF app and then code the UI to follow the instructions in my returned CommandResult object. However, I prefer a different approach. I wrote the MVC 3 UI to expose a JSON API. This API can be consumed by any application. The JSON API was simple because it was basically a wrapper around my Terminal.Domain project CommandResult object. The JSON returned would have the same basic properties. In this way I would write the WPF app to consume this API rather than the DLL. Now if I make minor changes to internal application logic I just deploy the Web project to the live server. All clients using the API automatically get this new logic.

很明显，如果所做的更改会影响从API返回的属性，那么这将需要发布新的客户端代码，但是至少对于内部逻辑而言，您不必这样做.

Obviously if the changes being made affect the properties being returned from the API then that would require a release of new client code, but at least for internal logic you wouldn't have to do that.

这篇关于如何在WPF和ASP.NET MVC应用程序之间共享最多的代码?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！