我遇到的主要问题是,在大多数演示中,我看到大多数业务逻辑最终都是RIA Services域服务类中的DataAnnotations和自定义验证.这对我来说似乎不合适.我认为域服务基本上是一个美化的Web服务,恰好可以很容易地将信息推送到客户端.但是我所看到的大部分内容似乎都将域服务定位为应用程序中业务逻辑的主要来源.
所以,我的问题:
>使用此堆栈的应用程序中业务逻辑(规则,验证,行为,授权)的最佳位置是什么?
>在架构级别上是否发布了使用此堆栈的指南?
我的问题涉及大型,复杂和长期存在的应用程序.显然,对于仅少数屏幕的应用,这不是一个问题.
编辑:
我要提到的另一件事是,显然你可以使域服务类变得愚蠢,但是你会丢失很多被推送到客户端的自动实体信息(例如验证).如果你输了,那么使用RIA服务有什么意义吗?
到目前为止,我注意到以下好处:
>域类是放置业务逻辑(包括复杂验证)的好地方.
>域类使用RIA实体和上下文作为数据存储的接口.
>域类是根据业务问题建模的,不需要与RIA实体建立一对一的关系.
>简单的UI验证可以存在于viewmodel中.
另外需要注意的是,我们已经实现了自己的并发身份映射,并将脏跟踪推送到RIA上下文.
实际上,这种架构需要更多的编码工作,但在可读性和可维护性方面可以节省大量时间.即使对于简单的CRUD应用程序,我也会遵循这种做法.能够构建更准确地表示问题空间的域模型是一个引人注目的优势.
总结以上是内存溢出为你收集整理的.net – RIA服务层有多少业务逻辑?全部内容,希望文章能够帮你解决.net – RIA服务层有多少业务逻辑?所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)