大家在项目中是如何处理关联查询返回结果的。

Question

      大家在项目中是如何处理关联查询的问题的， 要么是直接在项目中写个长sql，要么是写成存储过程，后者肯定居多，前者肯定也有。 但是返回DataTable后，绑定UI grid时又大多数是Json格式，今天碰到一个页面数据自己用存储过程返回DataTable, 然后又写了个Model， 循环table返回List<Model>. 需要自己的格式用Linq再处理，想想数据复杂了，除了单表查询外其余都需要用存储过程处理，那么又需要手写多少个Model呢，
      不知道大伙平时是怎么处理这种情况呢？

Answer 1

好问题，我是用dt的，深感恶心，求大神提出更好的解决方案。
用model我觉得不现实，条件变一点点，就要重新写。
估计用orm可以解决这个问题，目前正在学

Answer 2

请楼主先说明你是用asp.net webform还是asp.net mvc，因为这二者的解决方案是截然不同的。

Answer 3

先给你一个模糊的答案：你的DataTable已经返回了所有你所需要的东西，而你又“偏执”的把所有东西转成List<Model>——这又是何苦。你之所以这样做，也许是因为你觉得“这样显然是有必要的”——这说明你其实是bottom-up的开发方式。如果你转换一下思路，从上至下进行开发，比如你用MVC：那么显然我需要一个页面的Model（注意，这个Model跟数据层没有任何关系），这个Model包含所有你这个页面所需要的信息（也就是一堆属性其实）。你最终的目的便是满足这个Model的属性——即给它们赋值，至于你的数据是如何取出来的，又是如何赋值的，这都是很灵活的。这个例子唯一的目的就是告诉你：不要从数据库的角度去考虑——我应该取出哪些数据给哪些UI，而是应该反过来——先考虑我的UI是什么样子的，需要什么东西，然后再考虑下层结构。

Answer 4

还有你要注意的是：没有任何两个不同的项目可以用完全一样的开发方式，你必然要为它们单独做一些customization——这在实际开发中是不可避免的。所以不要总想着：我一定要返回一个List然后再输出，或者类似所有这些类都必须继承某个基类等，有时候你需要做一些妥协。优先考虑测试驱动，从上至下，先有设计，再有页面，再有下面数据的设计等。你做的一切都是为了满足客户需求和设计需求。

Answer 5

处理成List时因为我想使用Linq将其中的数据再做一些处理，如果同时也需要在页面显示呢，MVC页面里基本上使用的都是强类型。 那么UI需要的这个关联查询Model又如何处理呢？ 

Answer 6

楼主是否考虑过用 SQL CLR 数据库项目，可以自定义存储过程，或用户自定义函数，让sql 查询输出Json或xml或其它序列化的类

Answer 7

我是这么弄的，先建立个数据源 ，在数据源里弄个视图，然后放在datatable里

Answer 8

把数据库实体为对象。
表为实体的属性你返回什么数据都可以填充这个对象。
用linq前台使用数据