(.NET)关于Repository的SearchCriteria的动态查询设计问题
0
悬赏园豆：15
[已解决问题]
解决于 2015-03-11 23:04
假设我的应用为如下层次
A -「应用控制层」
B -「服务逻辑层」
C -「数据访问层」
「数据访问层」采用Repository模式，Repository封装常用的增/删/改/查操作。
包含如 Insert(),Update(),Remove(),FindAll() 等数据操作方法，对于FindAll()等这些查询方法
一般我们会使用Expression<Func<>>表达式作为参数，方便在「服务逻辑层」根据实际业务
动态拼凑LINQ的Lambda表达式，进而满足我们的查询需求。对于Lambda表达式我期望只暴露
到「服务逻辑层」，在「应用控制层」不允许直接使用Lambda表达式进行查询，因为会这样直接
暴露了EntityFramework的实体对象，让「应用控制层」直接耦合了「数据访问层」。
根据以上需求，希望在「应用控制层」调用「服务逻辑层」进行查询（比如FindUsers）的时候
能够使用类似SearchCriteria这样的方式进行动态查询，也许有同学说使用Specification<T>
Specification<T>也只是包装Lambda表达式而已，无法做动态查询。
我的想法是「应用控制层」使用SearchCriteria采集搜索条件，在「服务逻辑层」进行转换成为
Lambda表达式，进而交给「数据访问层」进行查询。
所以小弟想征求下各位的建议，想看看大伙是如何处理这个问题？什么样的解决思路或者方案？
最佳答案
0
暴露了EntityFramework的实体对象
「应用控制层」直接耦合了「数据访问层」
能这么推断？你的意思是只要MODEL让应用层知道就耦合了？
那咋办？再弄个DTO出来？
收获园豆：15
ff
ff
大叔,首先多谢您的回复^_^
我是这么想，我担心耦合，也纠结在这个地方，欢迎您的建议！
哎呀，我回头看了我的问题，有个地方需要说明下，我指的「应用控制层」 应该包含两种情况：
A. 如果是单个纯应用程序，那「应用控制层」直接使用「数据访问层」大部分情况下我可以接受！
B. 如果是个组件，需要提供给第三方应用调用，如果直接把「数据库访问」的模型暴露出去，
我觉得不太好吧，以我的理解那应该要引入 DTO进来。如果引入DTO，回到我的问题上面，
如果我需要在「应用控制层」上使用SearchCriteria，那我应该如何做设计？最终不管我的
SearchCriteria使用什么方式，我在「应用控制层」里面把Criteria转换成为LinQ或者SQL，
最后交给「数据访问层」去执行，然后返回结果，结果以DTO形式输出。
@kaleyroy:
1、从Entity到DTO这儿有一次转换上的性能损耗。
2、Entity本身就是Model。
3、Model你可以理解为Protocol。
4、你一定要有一个双方接受的Protocol。
5、所以纠结点通常在服务端，
是用Native ADO.NET转DTO 这个牺牲了开发员的效率
还是Entity Framework 这个担心应用层瞎搞
还是Entity Framework to DTO 这个转换时有性能损失
6、后两者主要是为了开发者效率，牺牲一点点性能。（这个是测试可接受的）
7、你可以看看CSLA。基本上就是DTO模式，而服务端不限制，开发者愿意Entity就Entity，
愿意Native ADO.NET就Native，或者还可以Redist。
@kaleyroy: 给第三方的肯定另外做Web Service啥的啊，哪里可能什么都给。
@爱编程的大叔:
嗯，这个我可以理解，做成WebService或者Restful这个问题不大。
可如果 是个组件，通过直接引用DLL的方式给第三方应用程序调用呢？
@kaleyroy: 那你就经常拜拜，祈求天主保佑吧。
@爱编程的大叔:
哈哈。。。，大叔您太幽默了^_^
最后一个问题，对于我问题里面的（SearchCriteria）通用搜索设计，有什么建议吗？
@kaleyroy: 我这两天在看SOD.NET。
好像医生就是这么设计的，不过分层设计本身就是一个大话题。
之前看CSLA.NET也有实现Criteria，你都可以参考下。
@爱编程的大叔:
好的。
其他回答(1)
0
ff
兄弟，您“ff"是？
@kaleyroy: 不好意思，这个是某个无聊的时候灌得贴，好比1/0;
