发布一款强大的ORM工具--PDF.NET集成开发工具
PDF.NET数据开发框架之集成开发工具Ver 4.1发布 ，PDF.NET数据开发框架 是一套轻量级的快速数据开发框架，它具有iBatis类似的SQL-MAP特性和Hibernate的ORM持久化特性，但不使用反射，整个过程几乎没有复杂的配置，非常适合新手使用和大虾研究。
 
整个框架提供了核心类库，代码生成工具和集成管理工具。
 
PDF.NET集成开发工具 Ver4.1 体验版安装程序，除了可以生成实体类，创建和管理SQL-MAP文件，自动生成DAL层代码，也可以作为通用数据库访问工具使用。
 
本版本可以直接支持下列数据库：
SQLSERVER
SQL CE
Oracle
Access
MySQL
PostgreSQL
 
SQLite版本的没有直接发布，但只要继承了 AdoHelper 抽象类就可以非常方便的实现。
 
下面是集成开发工具效果图（访问MySQL）：
[img=http://download.codeplex.com/Project/Download/FileDownload.aspx?ProjectName=ft&DownloadId=233284][/img]

详细信息和下载地址请看原文。


------解决方案--------------------
顶，真的很强大的
------解决方案--------------------
太感谢啦。。。我研究下。。呵呵。。
------解决方案--------------------
从技术的角度看，lz的想法是好的。

但是从商业的角度看，存在一些问题：

（1）开发者能不能得到技术支持的保证？培训谁来做？
（2）后继的维护谁来做？BUG修复？
（3）ORM的框架众多，lz的产品优势在哪里？定位简单还是功能强大？如果是简单，lz的这套语法/函数还是略显复杂。
（4）对于一款面向.NET的ORM框架，如果不兼容 IQueryable 接口是一种相当大的遗憾。这意味着，我还必须使用面向数据库架构的语法来操纵业务逻辑。
（5）支持很多数据库固然很好，但是lz如何处理数据库方言问题？对于大部分低端用户来说，能很好很简便地处理好MSSQL就很不错了。对高端用户来说，支持多数据库并不是唯一的需要，他们需要稳定、高效以及高伸缩性和可扩展性。说到底，还是定位问题。目前的Entity框架就做轻量，它无论是和IDE的整合，还是ORM以及和语言的整合，做的都很好。比如ModelFirst、CodeFirst或者根据表建模，而lz的方案看上去需要在数据库和模型代码之间定义两次，而且没有很好将数据库架构和模型分离。
（6）ORM本身的复杂性没有用过的人很难想象。lz因为既是使用者，又是开发者，所以有思维定势——如果我100%是这个框架的编写者，或者我对框架的所有实现完全掌握，我甚至会考虑使用自己的框架代替通用的ORM。但是，如果我不是框架的设计者，没有阅读过全部源代码（即使你提供代码，我有没有力量去读还是个问题），那么你假想的“轻量”、“简单”都是不存在的。简单的东西不是绝对意义上的简单，而是可以充分借鉴现有的知识以及对它的反馈有充分的把握。
（7）有没有能够说服我使用它可能并不是一个简单的例子，查询几条记录，事实上对比所有同类产品，实现这样的功能都很容易。我说几条EF的问题，不知道你的产品能否解决：
 - 对于泛型实体的支持，假设我要设计一个考试系统：

class Questions<T> where T : QuestionBase { }

{

    public List<T> Questions { get; set; }

}

class QuestionBase { }

class SingleSelectionQuestin : QuestionBase

{

    public string Description { get; set; }

    public List<string> Options { get; set; }

    public string Selected { get; set; }

}

class MultiSelectionQuestin : QuestionBase

{

    public string Description { get; set; }

    public List<string> Options { get; set; }

    public List<string> Selected { get; set; }

}

class BriefAnswerQuestin : QuestionBase

{

    public string Description { get; set; }

    public string Answer { get; set; }

}

这种情况下，使用目前版本的Entity框架，我必须迁就数据库的设计，这就是目前ORM缺陷的原因。
- 对于多实例可扩展性的支持
比如我的数据库部署到 SQL Server Azure 上，我的程序托管在Windows Azure WebRole里面。可能我有10个WebRole，并发访问数据库，数据一致性怎么保证？
- 非常复杂的数据库关系和架构，比如多个外键，级联查询，唯一性约束，参照完整性约束。比如自定义函数和SQL类型等等
- 数据迁移问题，说实话，数据迁移是几乎所有人都关注的核心问题，而且是衡量ORM好坏的首要标准。对于一个渐进添加功能的Web程序，程序的升级，同时保证原有的数据平滑地迁移到新的数据库里面是非常重要的事情。对于Rails的ActiveRecord，就做的很好。迁移几乎自动进行，甚至还可以反向的迁移。
在闭源产品（我是说.NET）上开发，这条路很艰辛，很多很大的产品相继倒下了，lz要慎重。
------解决方案--------------------
楼上v5
------解决方案--------------------
恩，需要考虑很多问题。
------解决方案--------------------