Mar*_*ans 7 c# wcf design-patterns wssf
我们正在使用WSSF构建WCF Web服务.我们的想法是,它将通过服务公开我们的主数据库,并允许我们在服务之上构建各种应用程序和网站.目前我正在构建一个简单的客户端应用程序,它将从此服务下载一些数据,对其进行操作,然后将其作为报告CSV文件提供给用户.
现在问题是应该在哪里定位业务逻辑(操纵数据)？我想我会把它放在服务中.我已经有一个业务层,其中有简单的对象,几乎与数据库(客户,订单等)一对一映射.我想我会制作一些"更高级别"的对象来操纵数据.例如,通过使用客户,订单和其他对象并生成报告等.我认为最好的地方是服务的业务层.这样,如果需要,我们可以将此逻辑重用于各种不同的应用程序.
不幸的是我的老板不同意.他希望"分离关注点",并说这个逻辑的正确位置是在客户端应用程序内部的业务层而不是服务中.我想这可能更简单,但我想在服务业务层内使用我强大的对象模型来编写此代码.服务公开的对象不是"真实"对象,实际上只是轻量级数据结构,没有服务业务层内部存在的完整对象模型的强大功能.
你们有什么感想？
我的投票很明确:
为什么数据库
任何形状或形式的SQL都有一些非常基本和非常强大的检查功能 - 确保内容是唯一的,确保表之间的关系完整性是给定的等等 - 使用它!如果您在数据库中进行这些检查,那么无论您的用户最终如何连接到您的数据(恐怖场景:管理员能够使用Excel直接连接到您的桌面以执行某些商业智能工作......),那些支票将到位并将予以执行.强制数据完整性是任何系统中的最高要求.
为什么服务器上有业务逻辑？
其他回答者提到的原因相同:集中化.您不希望仅在客户端中拥有业务逻辑和检查.如果您公司的其他部门或第三方外部顾问突然开始使用您的服务,但所有的验证和业务检查都没有到位,因为他们不知道他们怎么办？不是一件好事......
客户端中的逻辑
是的,当然 - 您还想对客户端进行一些简单的检查,特别是如果它是一个Web应用程序.应该尽早执行"需要此字段"或"此字段的最大长度"等内容.理想情况下,客户端会从数据库/服务层自动获取此信息.ASP.NET服务器控件具有可以自动打开的客户端验证,Silverlight RIA服务可以在后端数据模型中获取数据限制并将它们传输到客户端层.
我认为什么是“正确”取决于您的应用程序架构。关注点分离当然是有价值的。听起来你的老板觉得当前的模型是使用服务器作为数据访问层，将数据库映射到业务对象，并且业务逻辑应该在客户端实现。
无论业务逻辑是在客户端还是在服务器上实现，您仍然可以进行关注点分离。重要的不是在哪里进行处理，而是您设计应用程序各层之间的接口的干净程度。
更多地了解客户可能会有所帮助。您正在处理浏览器/Javascript 客户端吗？如果是这样，那么我会在服务器上保留尽可能多的处理，并或多或少以您希望显示的形式将数据发送到客户端。
如果它是 C# 客户端，那么您在这方面拥有更多的能力。您可以将 WCF 服务的响应重新构建到您在服务器端使用的相同业务对象类中，并获得与在服务器上相同的功能。（只需在两个解决方案之间共享业务对象类即可。）
| 归档时间： |
|
| 查看次数： |
2501 次 |
| 最近记录： |