将业务逻辑放在 WCF 服务中还是将代码放在 Silverlight 控件上更好？
在尝试为 Silverlight 应用程序设计架构时，我想问是否最好：
使用带有 WCF 数据服务的实体数据模型，然后将我的业务逻辑放在我的 silverlight 用户控件的代码隐藏中对从 WCF 数据服务返回的纯数据进行任何修改/管理
，或者
将实体数据模型与 WCF 服务结合使用，然后使用 [OperationContract] 方法将我的业务逻辑放入实际服务中，在该方法中我可以在服务级别应用我的业务逻辑从而在演示（silverlight）和业务（服务）之间提供清晰的分离。
任何人都可以就哪种方法更好提供意见，或者是否还有我在上述建议范围之外尚未发现的更好方法？
谢谢
In trying to design an architecture for a Silverlight application, I am at a point in asking is it better to:
use an Entity Data Model with a WCF Data Service and then put my business logic in the code-behind for my silverlight user control to do any modifying/managing of pure data returned from WCF Data Service
or
use an Entity Data Model with a WCF Service and then put my business logic in the actual service using [OperationContract] methods in which I can apply my business logic in the service level thereby providing a clean seperation between presentation (silverlight) and business (service)
Can anybody provide their opinion on which approach would be better or if there is yet a better approach that I have not discovered outside the scope of my suggestions above?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我个人会使用上述组合（经过修改）。
我会根据需要将业务逻辑和业务规则放入您的 WCF 服务中。这有很多优点，包括允许服务执行所有数据验证和检查（在任何情况下都应该这样做），而不需要发生两次。这促进了未来应用程序的服务重用，因为其中的逻辑是特定于领域的，并且不依赖于特定的表示层或应用程序设计。
话虽如此，我不会将特定于此应用程序的逻辑放入服务中。相反，我会使用 MVVM 方法，并将特定于应用程序的逻辑（与业务规则分开）放入 ViewModel 类中，并从 Silverlight 视图中使用它。我会尽量避免使用代码隐藏作为注入逻辑的地方 - 无论是特定于应用程序还是业务规则。
I would, personally, use a combination of above (with modifications).
I would put the business logic and business rules, as appropriate, into your WCF service. This has many advantages, including allowing the service to do all of the data validation and checking (which it should, in any case), without requiring it to happen twice. This promotes reuse of your service for applications in the future, since the logic there is domain specific, and not tied to a specific presentation layer or application design.
That being said, I would not put logic specific to this application into the service. Instead, I would use an MVVM approach, and put the application-specific logic (separate from the business rules) into a ViewModel class, and use this from your Silverlight views. I would try to avoid using code-behind as a place to inject logic - whether application or business rule specific.
我不会将业务逻辑放入实际服务中。该服务是一个服务接口层
本质上，它提供了一个接口（一个API）在您的“系统”和外部世界之间。在这种情况下你的用户界面。
所以你仍然需要一个有你的逻辑的业务层。服务接口层与业务层对话，并将方法和数据作为 WCF 服务呈现。
I wouldn't put the business logic in the actual service. The service is a Service Interface Layer
Essentially, it provides and interface (an API) between your "system" and the outside world. In this case your UI.
So you still need a business layer that has your logic. and the Service Interface layer talks to the business layer and surfaces the methods and data as a WCF Service.