sti*_*k81 6 .net architecture wcf structure
我有一个WPF应用程序,到目前为止只是客户端,但现在我正在努力将其分为客户端和服务器端.在这项工作中,我正在为客户端 - 服务器通信引入WCF.我的应用程序有几个项目,并且需要多个项目的服务引用.
做分离的最初努力是"直截了当"地做所有事情.需要与服务通信的所有项目都获得服务引用,主WPF应用程序项目也是如此 - 在那里获取app.config.我觉得这很快变成一团糟,我无法想象这是人们使用的典型架构吗？我也看到了每个服务引用生成DataContract类的新实现这一事实的问题 - 因此在项目交叉上没有对DataContract类的共同理解.我在一个项目中有一些ViewModel类,另一个项目实现了一些ViewModel.我想传递从服务中收到的对象,但我不能,因为每个项目中收到的对象的生成的客户端表示不同.
那么 - 是否有建议使用WCF构建此类客户端/服务器分离的方法？还是要遵循的原则？我在想客户端上使用的一个常见代理项目,它与服务进行通信,包装接收到的数据,并在客户端库知道的表单上返回数据.应该只提供一个服务引用,我想我只需要wpfApp项目中的App.config？这有意义吗？
mar*_*c_s 16
我喜欢这样构建我的WCF解决方案:
合同(类库)
包含所有服务,操作,故障和数据合同.可以在纯.NET到.NET方案中在服务器和客户端之间共享
服务实现(类库)
包含实现服务的代码,以及实现此目的所需的任何支持/帮助方法.没有其他的.
服务主机(可选 - 可以是Winforms,控制台应用程序,NT服务)
包含用于调试/测试或可能还用于生产的服务主机.
这基本上给了我服务器端的东西.
在客户端:
客户端代理(类库)
我喜欢将我的客户端代理打包到一个单独的类库中,以便多个实际的客户端应用程序可以重用它们.这可以使用svcutil或"添加服务引用"并手动调整生成的可怕app.config,或者通过使用ClientBase<T>或ChannelFactory<T>构造手动实现客户端代理(共享契约程序集时)来完成.
1-n个实际客户端(任何类型的应用程序)
通常只引用客户端代理程序集,或者也可以引用合同程序集(如果它正在共享).这可以是ASP.NET,WPF,Winforms,控制台应用程序,其他服务 - 您可以命名.
那样; 我有一个漂亮而干净的布局,我一遍又一遍地使用它,我真的认为这使我的代码更清洁,更容易维护.
这是受到Miguel Castro的极端WCF屏幕的启发,该屏幕采用了DotNet Rocks电视和卡尔富兰克林 - 强烈推荐的屏幕演员!
| 归档时间： |
|
| 查看次数： |
4472 次 |
| 最近记录： |