最近开始看LINQ，给人以耳目一新的感觉，用起来也很方便。
但是如果在系统中使用LINQ，那么是不是与常用的三层架构有冲突呢？
不再需要实体层与数据层了，直接就可以在表现层取数据进行展现了。
有点困惑，请大家给点意见！
-----------------------------------------

首先，LINQ是查询技术，楼主可能误认为LINQ 只有那个  LINQ to SQL 了，实际上还有别的， LINQ to DataSets , LINQ to Objects 等。
如果用上 LINQ to DataSets，是不是就和原来一样呢～～


这个问题这么分析一下吧。
首先是三层 ，我的理解是 表示层，逻辑层（业务），数据访问层（DAL）（如果我有说错的话，可以提出来。^_^）

那么，LINQ 是做什么的呢？根本来说，就是查询（废话了，名字就是那么起的）。
既然是查询（搜索，查找）的话，只要需要就会使用的。 以前可能搜索的时候，可能使用DataTable的DataView来处理（我是这么做的，因为实在本地处理，另外也要加载所有数据），那么现在就可以换LINQ来处理。

啊，好像说跑题了。。

说说楼主的疑惑吧，不知道楼主说的实体层是什么，
其实，直接把LINQ to SQL 返回的实体，返回给上一层不久OK了。
以前可能使用DataSet包装的， 之后可能是自己的自定义类型（这个我干过，很累啊）， 现在返回 LINQ编译的实体。也应该是一样的。（安全问题先不说了）那么上层处理的数据，只是变成了实体而已。

至于楼主说的在表示层处理，实际上也是可以分离的吧。如果能分离的，那就可以放到DAL里了，不能分离的，如一些搜索，过滤等，那就放到表示层吧。

总之呢，层这种东西，是逻辑上的抽象， 实现的时候可能放在任何位置， 大的程序可能会放到类库（DLL文件）里，小的程序可能会直接放在程序中的某个类或命名空间下等。

好了，以上是我个人意见，有错误请指正。
------------------------------------------------------------------

看到过LINQ to DataSets , LINQ to Objects，但还不了解这些的具体功能。
实体层是对数据库对象的映射，对LINQ应该就是dbml文件了。感觉上dbml文件和实体层的功能是一样的，不知道是不是这样？
现在的系统多是在三层或多层架构之上，既然推出了LINQ，我们肯定是想将其应该到现在的架构中去，不知道有没有这方面的应用可以参考借鉴一下？
---------------------------
我现在也没有用过 DataSets，Objects 还是用过， 基本和遍历数组差不多
哦，知道了，实体层是对数据包装，我之前是把它放到 DAL里 了
事例嘛，目前我也没有看到一些关于3.5 的示例，不过应该会很快出来的
虽然LINQ 可以查询数据库，并返回，  但不一定其他位置就可能不会用到
查询数据库的，是在数据层， 但其他层里，有些查询（遍历）也可以用到

-------------------------------------------------------------
LINQ的确给人耳目一新的感觉，因为其是C#3.0扩展的新语法，直接将查询语言与编程语言集成在一起了，用起来确实方便。
这并不影响系统的分层设计，分层设计依然是软件设计的好方法，只是你又有了更厉害的武器LINQ而已。
但你不能因为有了这个宝贝就处处使用它，因为并非所有的地方都适合LINQ的。
LINQ毕竟是通过离散的内存对象来访问数据的，在海量数据处理的应用中，建立一个个的内存对象来处理数据的开销往往是天文数字。所以，O/R Mapping一般都是用在处理少量数据的情况，对象化的处理可以带来方便。
还有就是查询语言与编程语言集成也带来另一个问题，就是查询代码的“硬化”。所谓代码硬化，指的是代码被人为或自动写死，并在运行时不可更改。也就是说，“硬化”的代码遇到数据结构变化或查询需求变化时，需要重新修改源代码，再生成运行版本，这是“硬化”代码的通病。
而以前的SQL语句本身是编程语言的字符串数据而已，因此可以把SQL逻辑独立出来形成外部SQL文件或数据库内的存储过程，当数据库需求变化时，可以在不停止系统运行的情况下修改这些SQL逻辑完成需求变更。甚至有些做得好的数据库系统是以“数据字典”驱动的，数据结构的任何变化都不影响编程语言的源代码。
当然，你也可以通过动态生成LINQ并即时编译的办法来独立查询逻辑等，有兴趣可以试试。
总之，任何东西都有利有弊，要看具体情况而定。表现层、业务层和数据层也并非一定要从物理上划分，只要逻辑上存在分层即可，只要简化设计帮助人们理解即可。