@Weatherreport
这样处理是不错，但是根本的问题还是没有解决。

@Jeffrey Zhao
多库分布是必须要考虑进去的，如果没有多库，则没有必要搞的那么复杂。最终的难题，我估计应该会在多库分布这个核心点上面。

@Jeffrey Zhao
主要是我在完善自己框架中间遇到的一些问题，用现在MS提供的架构不容易实现，感觉灵活性不够吧。
这个如果有机会一起坐下来聊聊倒是不错的。
在这里写，要写的太多了。

希望的架构，一句话可能说不清楚。
我希望的架构应该是经典的三层构架：数据库层/应用服务层/客户端
客户端提供数据的双向绑定：要求数据是自治的，基于事件触发的。

@Jeffrey Zhao
呵呵。Table<>;与DataTable。
DataTable是支持绑定处理的，以数据为中心的。
Table<>也支持绑定，也是以数据为中心的。绑定数据的变化也是记录在Table<>里面的。
对于远程应用：ADO.net常用的数据传输是以DataTable传输，而Linq TO SQL 也是以Table<>;传输的。这里或多或少都是有非常多的相似的地方。Table<>;也可以以List<>;等其他方式传输，但是客户端的绑定，却会出现一些其他引起的问题，灵活性不足。重写绑定机制当然也可以，但是这就不是纯正的MS提供的架构了。在Table<>与业务逻辑层的与服务层、客户端没有提供松散的处理机制或思想，与DataTable的处理思想是类似的。
这只是我的感觉，表达的不一定正确。

@Jeffrey Zhao
从语言层次上、基础构架上说，.NET比JAVA只好不差。领域模型与业务逻辑与具体技术无关也没有错。对于Domain Model，Java能做到的.NET同样能够做到，这点是不用怀疑的。但是在整个面向Domain Model的设计思想上，是指这方面的差距。当然，主要是指这方面人的差距了，包括人的数量上等。
提供的框架的灵活性，业务层组织、服务层组织等这些方面，当然这些有经验的人都可以解决的都不成问题，但是这方面的人是太少了。是指这方面的差距。

@Jeffrey Zhao
对于这样的应用是足够了，是非常方便的，不会有什么问题的，主要是应用场景不同。我感觉与ADO.Net的思想倒是有很多相似的地方。

@Jeffrey Zhao
这种思想，对于纯BS的应用，没有应用服务器的应用，这样的思想可以发挥出来，但是对于有应用服器的应用，就要多考虑考虑了。要么就多一些特殊的处理，当然，这些都是相对的。

@Jeffrey Zhao
就是在对于Table的返回，以及状态的处理，这些方面。
我感觉在业务层里面，不应该处理或者涉及到Table<>之类的东东，而是应该是一个普通的数组，数据应该是相对独立的，不然与Table或者Context的耦合太紧密，不利于业务逻辑的组织。ORM层就是负责ORM，不能再把业务逻辑也放在一起。在数据层可以存在表的概念，但在业务层不应该再出现类似于表的概念在里面。
对于客户端的数据绑定不应该与Table相关，数据也应该是相对独立的。包括绑定、触发、更新等。也不应该再出现表的概念在里面，客户端只与业务层或服务层相关。不管是BS还是CS，应该都是类似的。客户端应该只是薄薄的一层，封闭了对于外观的展现。

@Jeffrey Zhao
这样的处理是很好，是可以提高Web访问的并发吞吐量，特别是需要长时间操作的，对于有应用服务器的，Web客户端只是一个简单的壳的这种程序，我感觉更为合适。老赵举的例子，是比较简单的，而且逻辑层跟Web客户端在一起，可能会感觉提升不大，只是优化了数据访问。送花........

@xingd
这也是偶正想做的，把我的ORM换成用Linq实现，现在一直没有这个时间，前段时间主要是把客户端的代理实现重构了一下。如果下面有时间的话，我首先要做的第一件事，就是把DTO的级联触发再完善一下，第二件事就是把ORM换成用Linq实现，不会用MS的Linq TO SQL，应用的时候有太多限制了，特别是在业务逻辑层组织。

@怪怪
你说的很有道理，有点突破性的东西，不是Fowler这样的人做出来的，这倒是真的，多是某一个人憋出来的。
原来从05年的充血型模型到现在的贫血型，其实，刚开始的时候，我根本不知道我用的是充血型，后来才知道的。不喜欢重复的没有意义的工作，做完了一个项目之后，就给这个充血型放血了。
只是感觉现在园子里都是发些纯技术的帖子，心里有点不爽，整天Linq TO SQL的用法等等。没有谈论怎么能把ORM与业务层怎么很顺的结合起来，关键还是在于业务层的组织关联，我没有见到多少。我总感觉这些比具体的实际应用要关键多了。
园子里也没有分类之类，帖子很快就沉下去了，也没有人参与进来了。

@怪怪
我的意思您可能理解偏了。我心里是有答案，这种组织方式也在两个项目中得到应用，但是用了，并不能代码就好，就合理。就如泛形用在此处，合理吗？我不能给出一个确切的答案，虽然可以工作。能用不是代表就好，至少我这种代码组织方式，还有很多不合理的地方。我估计想要理清楚这方面的人，应该不是我一个，就是想讨论一下，能不能找出更好的组织方式和规则，把理论与实践结合起来，而又不拘泥于理论。这方面那么多的东西，不能单靠一个人就能做好的，每个人都有思维定式，需要多人讨论才能打破，形成一种更好的更明了的业务层的代码组织方式。这才是我的本意，希望怪怪不要理解错了。

@怪怪
我这里说的，并不完全是持久化与领域逻辑的关系。主要是针对业务层代码的组织，怎么样做，才能更清晰易懂，一个人写的代码另外一个人看起来不会产生阻力，当业务逻辑复杂的时候，能够容易把业务逻辑方便的组织起来，不会冗杂在一起。通过你的Track，也没有看到已经把“持久化与领域的关系”这个问题完全讨论清楚了，更别说业务层的代码组织了。
你说你不喜欢ORM，是因为制造了一大堆PO，那你不能通过别的方式处理，把能够隐藏的东西隐藏在后台处理，这也涉及到组织关系。
对于代码生成，代码生成只是辅助，代替人工工作，这些代码也只是个框架代码，人工要处理的就是在生成的代码上面加入逻辑。在程序里，核心业务的不是很多，超过20张表就比较少了。按80%与20%的原则，应该把80%的精力放在20%的核心业务上。

@zhangxd
对于些处用泛形实现，我刚开始也在考虑，到底应该不应该加，我现在也在考虑这个问题。
泛形重要就是强类型，此处加入泛形是为了处理继承问题。但是在现实中只用过有限几次。

对于CRUD，CRD是在Service的基类里实现的，R则是通过代码工具生成的。生成的代码与需要手工添加的代码用部分类分开存放，要手工写的基本上的业务逻辑的代码。对于通用查询，在基类里提供一个Protected的函数，根据情况进行公开。

基本的代码以生成为主。包括关联、数据类等、服务、注释等

@bmrxntfj
这样，你同样引用了两个对象。
在编码的时候，需要去分清，哪些是主动型的，哪些是需要多个对象交互的。
当是主动型的，放在Data类里面，但是如果是通过远程访问的，对于服务层同样要把这些主动型的动作公开出来。那么，服务层又要以另外的一种思想去考虑问题。当然，对于不需要分布的BS程序是可以的。如果应用服务器与Web服务器不在一台服务器上呢？
分清主动型这些操作还不如直接放在一个Service里面，两面相同的思维方式。没有必须转来转去，简单明了易懂，也是设计所要达到的。

我这里面，只谈些实际中遇到的问题，没有那么多的理论，一切为好用实用为原则，不会引经据典。都是实际中遇到的。

@怪怪
这是一个古老的话题呀，主要是看到园子里总是些纯技术方面的东西。另外，这方面的话题是个引子，这个讨论完，再出下一题，一层一层的来。
主要是讨论代码的组织、简单化。
您说CRUD不属于BL，但在很多情况下，CRUD却是组成这些业务逻辑的基础，这又怎么看呢？当然，也有些是虚属性(通过其他属性计算出来的)、不需要与持久层交互的规则，比如总金额＝单价×价格×数量等，要求单价必须在0~100之间等，这些是信息也可以写在Data里。
ORM我觉得，只是数据存取方式，也是为了减少人的工作量罢了，你就是直接用拼接字符串，也可以达到相似的效果。如果不用ORM，用存储过程？可能又会带来其他的问题，如果性能的瓶颈在数据库，又怎么办？

关于代码工具，如果没有代码工具，那么多的代码，总要人去写的，易出错，工作量大。前提是代码工具你自己是可控的。像集成开发环境的代码生成，我们是不可控的，还有其他的一些工具，生成的代码有其自己的规则，也算是不可控的。能生成为什么不生成呢？

@Jeffrey Zhao
处理的感觉是半手工处理，要很多人工代码参与进去。
示例上的代码与想像相似。是有Attach方法，但是达到的效果还有改进的余地。手工参与的还是比较多的。没有实现统一处理。

@Jeffrey Zhao
关键是序列化、反序列化之后，如果全部是在服务器端运行，不跨进程、CPU、网络，应该没有问题，是通过引用传递的。但是序列化传输之后，已经没有了DataContext，没有了Table，如何跟踪对象状态？

@Jeffrey Zhao
关键是如何记录变化了的数据，返回的List如何方便感知哪些数据是变化的，哪些数据是删除的，哪些数据是新添加的。因为从客户端传过来之后，则触发也断了，没有了Table<>，只有List如何处理呢？如果让手动去处理，那么，容易出错，工作量也是很大的。如果能把这个问题解决，我的ORM层会换成Linq。
从[Column(Storage="_CustomerID", DbType="UniqueIdentifier NOT NULL", IsPrimaryKey=true)]
public System.Guid CustomerID
{
get
{
return this._CustomerID;
}
set
{
if ((this._CustomerID != value))
{
this.OnCustomerIDChanging(value);
this.SendPropertyChanging();
this._CustomerID = value;
this.SendPropertyChanged("CustomerID");
this.OnCustomerIDChanged();
}
}
}

这里可以看的出，Linq的历史记录应该是保存在Table<>里的，我没有跟踪过，不敢确定。
当转换成List并序列化后，则这种关联应该去掉了。这种做法感觉是把单个对象与集合捆的太死，如果对象是单个的，则处理起来感觉有一些不方便，被束缚住了手脚。这也是比较困扰我的一个地方，我也想把这一块理清楚。
如果与我的服务层关联，也要对数据处理上加一些改造，还有业务层的组织，这些都要考虑，又是一个很大的工作量。
希望有机会能跟您探讨一下....

@Jeffrey Zhao
老赵，我是非常喜欢返回List这种类型，这样的后续处理好像与数据库无关了，因为是一个很通用的集合。
这里带来了一个问题，如果是远程处理，那么，用List这个返回数据还可以吗？
在服务器端，可能通过引用传递，变更是不用操心记录到后台的。有客户端如何处理呢？

@浅水滩
这两天看了粗粗的看了看微软的提供的MVC框架，感觉还是有些失望的，.net 方面给予架构、框架方面的太少，原来主要是集中在以数据为中心的开发模式上，现在来了一个MVC，感觉骨头里面还是面向数据的方式，在Domain Model方面跟Java领域的差距还是非常大的。
差距何止Controller这点点方面呀......

@orichisonic
兄弟是太看的起我了，我只是一个刚刚从部队转业3年的阿兵哥，由于喜欢软件，放弃了公务员选择了程序员，虽然年龄比较大，但是由于缺少在社会锻炼的黄金时光，现在只是在一个很小很小的公司打工，由于公司太小，真的不好意思说出来......

@henry
相同的感想呀
这就可能需要一个框架，用框架、工具来规范开发人员的这些代码，至少能够降低一些风险

@441144
层次越多越复杂，灵活性越强，越难驾驭，要在多种参数指标之间进行平衡。
对于常用的软件来说，框架和工具的支持，可能对于进度的影响是非常大的。

不知道大家在实现的项目里面，Linq用过多少，反正我是没有在项目里用过？对于升级、变更的灵活性等等，我心里没有底。所作的对比，都是基于微软提供的简单Demo和自己在此之上的想像发挥，可能会有很大很大的不到之处。毕竟，ORM这一块只是比较基本的一块。
希望大家一起把在项目中应用的体会加进来，这儿拉来一点，那里凑来一点的，不能从根本上比较差异。能够从整个软件的框架（架构）上去考虑，要站在全局的角度上去考虑分析....

@441144
关系信息肯定是在服务器端。客户端需要的数据关联是在数据传输层（DTO/SDO），在业务逻辑层的数据与传输层的数据中间要加一个转换，实现业务逻辑层的数据与显示数据的分离。显示层的数据是支持双向绑定的，业务逻辑层的数据是不支持绑定的。数据到了客户端之后，怎么处理就是客户端的事了。通常在客户端没有什么逻辑，逻辑全部是在服务器端处理的，客户端只是显示交互，因为传到客户端的数据就是客户端真正需要的数据。

@441144
谢谢，看了，是可以实现。怎么看起来感觉处理思想跟用DataSet差不多。没有把业务OO的优势真正的发挥出来，你的思想被这个有点束缚住的感觉，只是感觉，更具体的，我真的说不来。微软设计这套框架的时候，远程处理应该会考虑到的。从微软的一惯定位来看，就是快速发，容易上手，深入开发的时候会有些难度。
我的框架的每一层都是比较独立的，你可以任意的发挥，有很大的灵活性，每一层都没有过多的限制。就是面向接口和数据，其他的不用考虑。
可能是我考虑不全面，或者是什么其他的因素。

@441144
再加一个问题，如果Linq的类脱离了DataContext。界面数据的双向绑定，数据的变更如何自动记录？最终又如何把这些变更反馈到DataContext？如果是在公网上运行呢？

@Jeffrey Zhao
我感觉，其实都差不多。
我的界面处理是：
代理把数据从服务器端拉到客户端，然后数据通过绑定的方式显示在界面上，这里的绑定是双向绑定，内存的改变会反应在界面上，界面上的数据改变会改变内存里的数据，系统自动记录数据状态的变化。最后，把改变之后的数据提交。就是这样的处理过程，我不知道是用的什么模式。界面里面不包含逻辑。我不知道是MVC还是MVP，所以呢，我也不能过多的进行讨论。
谢谢，您说了MVP，我刚刚才查的，原来不知道的.....

@Jeffrey Zhao
处理是可以处理的，是可以用WCF，延迟加载也是可以控制的，也是可以进行序列化与反序列化的，只是一个Linq的类，可能对应着好几个要传输给客户端的类。如果用Linq的类，那么，软件就非常的死。打个比方，对于订单与订单明细来说，字段都很多，有时候客户端只需要订单主表的信息，有时候需要订单与订单明细的主从结构的信息一同带出来。有时候只需要订单的部分字段，这些变化，如果对应的Linq的类都写死的话，处理起来可能就会有些不方便。如果要灵活的处理，可能就需要有比较多的代码。Linq　To Sql只能说是实现ORM，业务逻辑还需要有一个规范的组织方式，这些之间的关系，等等。像一根线一样又会牵连出不少东西，这些都是与应用框架有关系的，Linq还是要与这些相结合的。

@441144
引用--------------------------------------------------
441144: --引用--------------------------------------------------
光影传说: @Jeffrey Zhao
@441144
Asp.Net 3.5 Extensions: Asp.Net MVC
只是实现MVC的一种方式
M和C　这一块我感觉可以延伸出很多东西。并不仅仅限于Asp.Net 3.5
很多大的分布式应用上面，从大的方面说也是一种MVC的结构，但表现出来，跟Extensions: Asp.Net MVC有很大的差异。
还有其他的很多实现方式。

--------------------------------------------------------
我觉得延伸及实现方式那是加肉加皮,骨头还是那块骨头
--------------------------------------------------------
没有错，骨头还是那根骨头，只是不能把C++等同于VC++了。一样的道理

@Jeffrey Zhao
我看着上面写的是MVC，如果是MVP的话，那我就不再多说了。那不就成了对不上号了吗？得赶快把名字改一下。

@Jeffrey Zhao
Linq的数据有很多是延迟加载过来的，在网络上传递数据通常是一次传递尽可能多的完整数据，这样一来，Linq的类的结构不适合直接在网络上传输。对于.net 常用的Web服务器和业务逻辑服务器放在一起，则比较适合。有的时候要提供BS+CS的界面，Web服务器是独立的服务器，而业务逻辑服务器（应用服务器）又在不同的服务器上，则在Web服务器与业务逻辑服务器之间要进行通信，那么Linq生成的数据结构则不适合直接在这种方式下进行远程调用。则可能要在上层再加一层包装，那么，又存在另外一套数据结构，这两个数据结构之间存在相关大的关联。
当然这只是从一个角度去考虑，还有其他的地方。
如果是用在一般的BS快速开发软件里面，从开发速度、执行速度上面，应该都能够得到保证，但是从集成性、伸缩性方面考虑，感觉稍微有点不足....

这只是我的感觉
谢谢老赵...

@Tristan(Guozhijian)
偶就是在说这个概念的....不然也不会那么说了，呵呵...

@Jeffrey Zhao
@441144
Asp.Net 3.5 Extensions: Asp.Net MVC
只是实现MVC的一种方式
M和C　这一块我感觉可以延伸出很多东西。并不仅仅限于Asp.Net 3.5
很多大的分布式应用上面，从大的方面说也是一种MVC的结构，但表现出来，跟Extensions: Asp.Net MVC有很大的差异。
还有其他的很多实现方式。

@Jeffrey Zhao
我说的，主要是指多数据源和具有独立的应用服务器的事。
这个方面用Linq也肯定可以处理，只是要再花不少的精力在上面。对于有应用服务器，则和服务层之间应该还要加一个协调层，包括数据格式的转换、服务接口等等。还有逻辑代码的组织方面，都还是要花很多的心思的。这就是ORM与框架的整合问题，如果只是一般的Web、业务逻辑不是非常复杂的应用，直接用Linq这种方式，我感觉是非常适合的也是非常快的。
如果加了一个协调层，则如何从Linq层到服务层的快速代码转换，也是要考虑的。个人感觉Linq不方便直接与服务层接口。
从性能方面，Linq是非常不错的，特别是查询，真让人心动呀。如果不是考虑到与框架的关系，多数据源的关系，肯定会采用的。
#34楼朋友的编辑器支持自动生成，其实这方面不是最重要的问题，只要工具的支持，直接把代码加入进来就好了，倒没有必要一定要如Linq 那种方面集成。
如果考虑到这些因素，把Linq集成到框架里也不是那么快的事情。

@Tristan(Guozhijian)
对于快速开发，这种方式非常适合，如果是对于分布式开发，有应用服务器等，我想就要更深入的考虑一下了。

@ocean
大致进行了一些测试，不能有代表性
Linq
构造10万条记录批量插入
插入：1'45s
读取：2s

ORM
构造10万条记录批量插入
插入：29s
读取：4s

Linq调用存储过程插入单条
构造1万条记录
用存储过程插入。
加入1'29

ORM调用插入单条
构造1万条记录
加入1'27

读取20万条
Linq　2s
ORM 4s

性能差异比较大的地方，就是在批量插入的时候。
其他地方的性能差异不是很大。

影响比较大的地方，大家应该很容易明白的。
我的数据读取有比较大的改进空间。Linq的数据加载是把延迟加载发挥到了极致...

@Jeffrey Zhao
因为MVC太大了......
包含的东西要比ASP.NET WebForms多的多

@ocean
如果按照您说的，也没错。是我自己把其归入反射的类的低效率调用的（纯属于个人原因）。
我的比较是有点问题，不是一种操作没有可比性，但是我的真正要比较是在执行GetCustomAttributes操作与不执行之间的比较，如果GetCustomAttributes的性能与getType之间的有类似的性能，那么多次调用GetCustomAttributes的性能差异可以不考虑了，可以进行多次执行，不会对性能产生多少差异。

关于性能，才是最终要进行的分析，我今天作一下性能测试比较，下午应该可以把比较参数拿出来了。如果性能差异在10%以内的话，就算没有什么了。

因为其用了System.Nullable，可以为空变量，那么，在从数据库取值的时候，就会在循环里少执行一次比较和其他处理，也会快一点。

不过，如果仅仅从性能上去分析，两者的差异不出意外的话，会在10%以内。我这边主要是用了他的存储过程映射方面了，处理思路应该是一致的，基于配置文件的映射方式，虽然提供，但是在项目里面也没有怎么去用了，就是用了一个可变查询。在ORM方面由于工具跟框架的支持也是不得不考虑的问题了。

@ocean
我是把GetCustomAttributes列为反射，对于typeof和type.GetType()这两个函数是不能把列入反射。
您列出调用性能差异是完全正确的。特别是后面的３种调用，性能差异是可以完全忽略的。
class Program
{
static void Main(string[] args)
{
Test test=new Test ();
Type type=typeof(Test);
FieldInfo fi = type.GetField("name");
Type desAttrib = typeof(System.ComponentModel.DescriptionAttribute);

Console.WriteLine(DateTime.Now);
for (int i = 0; i < 1000000; i++)
{
object[] t = fi.GetCustomAttributes(desAttrib, false);
}
Console.WriteLine(DateTime.Now);
for (int i = 0; i < 1000000; i++)
{
Type t = test.GetType();
}
Console.WriteLine(DateTime.Now);
}
}
[Serializable]
class Test
{
[System.ComponentModel.Description("Test")]
public string name;
}

虽然代码很丑陋，结果不准确，但是其超过100百的性能差异，我想是不能不考虑的。


“LINQ to SQL中是没有通过DataReader来读取数据的，而是重新写了一个读取引擎。 ”
对的，就如ADO.Net的DataReader与DataTable的DataReader也不是同一个DataReader，通常，这些DataReader之间的性能差异不会有那么大的，就是把数据从数据库读取到客户端。会产生比较大的性能差异的地方，就是如何把DataReader的数据加载的对象里面去，就是这一块的性能差异比较大。如果不把数据读进对象内存，只调用reader.Read()，那么速度是相当相当快的，做一下测试就知道了。

@ocean
是不会从数据库取字段信息，是保存在自定义属性里的，这个我知道。
[Unie2e.ORM.Mapping.FieldAttribute("City", "CityCode", false, SqlDbType.VarChar, 50, 0, 0, "城市代码")]
public String CityCode;
这个的表达方式，跟您提到的方式，应该是一致的。
我关心注意的也就是这些地方。
后台的数据读取应该都是通过DataReader读取的。
用我的这种数据加载方式，性能比用DataTable加载，性能要高30%~40%，这个我是在多次测试下，都得到相似的性能。
刚开始在没有进行优化之前，性能比用DataSet加载数据要慢60%。DataTable底层也是通过DataReader读取的，如果没有这些性能差异，我可能也不会太关心这些性能差异的。
在这一块对性能的影响还是比较大的。
对于DataReader如果只是循环，不进行数据加载，直接读取下一条，你再测试一下数据。

最好还是做一下详细的测试，如果你在上海的话，我们有机会的话，一起坐坐.

这里的测试条件还是比较多的。

@ocean
谢谢。我的理解错了。
“如果 CommandType 属性设置为 TableDirect，则 Prepare 不会执行任何操作。如果 CommandType 设置为 StoredProcedure，则对 Prepare 的调用应该会成功（虽然它可能导致无操作 (no-op)）。在 SQL Server 2000 和 SQL Server 2005 中，服务器会自动缓存计划以在需要时重复使用；因此，无需在客户端应用程序中直接调用此方法。”

谢谢！
我可以把这个函数去掉了，我考虑的太多了。
不过，这个Command的缓存还是需要的。
真的很感谢...

“LINQ语句->lamda表达式->expression tree->SQL语句”对于“LINQ语句->lamda表达式->expression tree”前面这部分，是没有用到反射的，相当于推理机。关键是从表达式树到Sql语句，因为数据在数据库中的表达方式与在应用程序中的表达方式不同，“DbType="NChar(5) NOT NULL", CanBeNull=false, IsPrimaryKey=true”，程序里不存在关键字，字符串只有一种类型只有一个最大长度限制，但是数据库中有关键字，多种类型可以映射到字符串类型，也有字符串的长度限制，有能不能为空的约束，那么Sql也要有这些，要通过自定义属性才能取出这些数据，这就要用到反射的地方，还有从数据库取出数据后的填充，主要的影响也就在这些地方。如果每执行一个Linq 都要进行一次反射的操作，那么对于程度的性能影响可能就要考虑了。一个50个字段的表进行10次插入操作，就要调用超过500次的反射操作，反射与正常执行的性能有近百倍的性能差异呀。这些我们都不知道后台是怎么处理的，全部都不知道呀，那么用Linq至少我当前不敢太多的考虑，只有非常清楚了，我才会考虑，那也要经过评估的。

@je
谢谢，已经改了。

@liangliangzai
谢谢！应该好好努力，一定！这一块是很乱，思路都很乱，不知道应该如何表达了

@rIPPER
呵呵。因为刚开始设计的时候还没有.net 下开源的ORM，一切都还算是原创吧，本人又是个OO的信徒，特别是.net2.0 beta 的推出后，给用OO可以说是注入了一个强心剂。从刚开始设计，到在第一个项目里面应用，花了不短的时间，进行了大量的测试，但是在第一个项目里面，还是出了不少的问题，中间可以说是一波三折呀。另外是起初的时候是想先解决存储过程调用的问题，因为存储过程的调用都是一样的，不能把精力浪费在这些地方。

当然，中间还是有很多不到的地方，请大家能够批评指正，多多交流。
当兵的十年，使我跟社会上有很大的脱节了，也没有什么技术方面的朋友....转业之后就开始设计这个ORM的。

真心的请大家能够批评指正，多多交流....

@ocean
“在IDbCommand接口上就定义了Prepare()方法，这个方法可以把CommandType为Text的SQL语句提前在数据库中编译为一个临时的StoredProcedure然后再执行，这样对于需要多次执行的DbCommand来说，可以提高一定的执行效率：）注意：请在指定了Command的Connection之后再调用Prepare()方法。 ”
上面的这句话我是从网上G下来的。

数据库的缓存、优化执行那是Sql、ORA做的，我们应用程序里不用关心的，他会根据情况进行优化处理。

我感觉Linq和SqlDataAdapter应该不是一种概念上的东西。
Linq与SqlDataReader也不是一个概念上的事。Linq 只是把表达式翻译成Command，最后应该还是通过DataReader读取的。

“每个LINQ都是翻译成一个SQL语句的，这里面是没有反射的调用的”，我没有一步一步的进行跟踪，但是如果不用反射是如何把自定义属性改变成数据库的列的，因为表达上我的自定义属性与Linq 的对象的表达是非常的相似的。

我认为通过Linq只是得到谓语和相关对象及属性，然后通过反射得到相关属性的数据库映射列，根据谓语生成Sql的命令字，生成完整的Command，再根据不同的Provider生成不同数据库对应的Command 。不知道我的理解是不是正确，请大家指教。

ORM也好，Linq也好，DataSet也好，最终都要通过调用最基础的Command 来执行命令。

@kiler
还有一本也算是经典的吧。推荐了下，《J2ee核心模式》，我的感觉还是很不错的，应该值得一读的。主要是读思想了，不过，建议还是先把楼主的这本书看完，再看这本书。

@kiler
对的，做项目，稳定是第一位的。一个框架的成熟也是要经过大量的项目的考验的，是要靠时间去积累的，更不是随便套两个设计模式就可以了的。模块、层次之间的耦合，也是非常关键的问题，这也是个系统工程。就好像中国的航天，划分到每一个小块，可能日本的技术都占优势，但是合起来，中国的就比日本的差不多要高一个层次。如果不能理解一项目新技术的设计目的，估计也很难把这项目技术真正用好，基础框架方面的都是牵一发而动全身的，不是说变就变的。
下面的介绍，肯定会有很多不到的地方，多给我提些批评建议。后面的部分难度也是非常大的，感觉比ORM的难度还要大，有的到现在还没有解决，以后请多多支持了。

@kiler
谢谢老朋友了。我这个框架的ORM部分也已经用了快要3年了。刚开始的时候只是一个ORM，后来慢慢的完善起来，才逐渐形成一个完整的框架的。开始的时候事务处理的不好，稳定性确实不够，后来几经改进，已经是相对比较稳定了。我也在考虑是不是要把我的框架开源了，毕竟靠自己维护着这么庞大的一个框架是很吃力的。