中财网海外博后招聘信息:对象关系映射概念性示例（怀疑ORM者请进） 1
来源：百度文库 编辑：中财网 时间：2024/04/29 04:47:03
- patrickpan
- (离别钩)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bonhomme
- 等 级：
另外你说的从DataGrid直接提交对实体对象的更改，好像和ORM本身没有直接联系，而且在数据访问层理关照UI的实现，从一般的架构原则看，似乎欠妥。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- lingshixiao
- (★圣殿骑士)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dagecc01
- 等 级：
关系管理,你说的应该是数据库表格的关系吧.
在C#代码里,我专门定义了
表格标签TableAttribute,
视图标签ViewAttribute,
存储过程标签ProcessAttribute,
函数标签FunctionAttribute
主键标签PrimaryAttribute
外键标签ForeignAttribute
列标签ColumnAttribute
表与表间的关系,在早期的版本中,是通过ForeignAttribute来标注的.
现在是通过实体类的组合来实现的.
[ORMCombination( "productInfo.productInfoType InnerJoin productTypeInfo.productinfotypeID ")]//如果采用不含形参的ORMCombination,系统会自动根据表格的外键信息来关联.
public class TestReport
{
public productInfo;
public productTypeInfo;
.......
}
------------------
另外,我这套不仅仅只是ORM的功能,还包括数据访问,AOP,IoC,日志,异常,缓存,安全与授权,简单工作流等组件,如果说有个实体类的容器,那加强这个实体类容器的功能是一件有必要的事.这正好符合我们的目的:快速开发ERP,敏捷反应客户的需求.
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dagecc01
- 等 级：
6月后,组件库会发布一个版本,开发会暂停.
8月后,我们研发组会转入图形学,唉.头大.
希望在未结束之前把东西做的更好.希望能在大家身上多学点知识.
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bonhomme
- 等 级：
我的肤浅感觉：你的东西与其说是ORM（对象关系映射），不如说是ROM（关系对象映射），或者叫DOM（DB object mapping，数据库对象映射），也就是说你的是以数据库为出发点，力求在C#对象中“一对一”映射“各种”“物理的”“数据库实现”概念，例如你说的表、视图、存储过程、函数、主键、外键等，奥，对了，你还缺了触发器，是写帖子的时候忘记列出来了吧？
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- friky
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dagecc01
- 等 级：
我的肤浅感觉：你的东西与其说是ORM（对象关系映射），不如说是ROM（关系对象映射），或者叫DOM（DB object mapping，数据库对象映射），也就是说你的是以数据库为出发点，力求在C#对象中“一对一”映射“各种”“物理的”“数据库实现”概念，例如你说的表、视图、存储过程、函数、主键、外键等，奥，对了，你还缺了触发器，是写帖子的时候忘记列出来了吧？
=======================================
to bonhomme;
下面是来自: http://www.javaref.cn/topics/Hibernate/1458.html 的一段话:
-----------------------------------------------------------
2、什么是ORM？
ORM（Object-Relation
Mapping）是对象-关系映射，当下流行的开发语言都是面向对象的，如Java，C#。而当下流行的DB大多都是面向关系的，也就是关系数据库。这样在面向对象与面向关系之间需要一个桥梁，才能使二者协同无缝联合工作，ORM就是这个桥梁。映射关系如下：
[类] <=> [表]
[对象实例] <=> [表的行]
[属性] <=> [表的列]
那么这些映射关系是如何制定的呢？——只需要一个映射文件（XML）即可，在其中配置持久化类与DB表的映射关系后，ORM中间件在运行时参照此文件内容，对象持久化的DB中或把DB中数据加载到持久化类中。
Hibernate就是一个卓越的ORM中间件。
-----------------------------------------------------------
他说的很简明: 面向对象语言要与关系数据库之间有个桥梁.
只要做到了这点,就可以算是ORM.
ORM本来就是以数据库为出发点,为的就是要解决OO与关系数据库的映射.让程序员去少写SQL语句.
写在string 里的SQL语句,在编译的时候是无法发现错误的.更改了数据库的字段名称,就算现在的IDE有重构,但是你要重构字符串,那也是一个噩梦,他会把一些不需要重构的字符串也替换掉.
为什么要有函数和存储过程,这个是为了用户更加方便的调用.有很多老的系统,里面存在大量的存储过程和函数,新的系统要使用老的数据库,支持函数和存储过程,我认为是很有必要的.
为什么没有触发器,嘿嘿,我不喜欢这个东西,所以就没有.很多ORM还不支持存储过程和函数呢.
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dagecc01
- 等 级：
15、什么是ORM？常用的ORM架构有哪几种？
ORM是对象关系映射（object relation mapping) 。一种将关系型数据转化城面向对象数据进行处理的过程。就是为了不让在逻辑层看到大量的SQL语句。将关系型数据库中的数据（往往妨在表中）采用一种映射mapping，（通过XML文件的方式），转换成直接用面向对象的语言去操作，这样就可以避免使用SQL . 常用的ORM框架有：java中hibernate。.net中的nhibernate和grove 。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dagecc01
- 等 级：
什么是ORM?
对象角色建模（ORM）提供了概念性的、易于理解的模型化数据的方法。ORM方法论基于三个核心原则：
· 简单。以最基本的形式建模数据。
· 传达性。数据库结构被任何人都能理解的语言文档化。
· 精确性。基于数据模型创建正确标准化了的结构。
典型地，建模者通过收集来自那些熟悉应用程序但不熟练的数据建模者的人的信息开发信息模型。建模者必须能够用非技术企业专家可以理解的术语在概念层次上与数据结构进行通讯。建模者也必须能以简单的单元分析信息，对样本数据进行处理。ORM专门被设计为改进这种联系。
规则表达式
ORM把应用程序世界表示为具有角色（关系中的部分）的一组对象（实体或值）。ORM有时也称为基于事实的建模，因为它把相关数据描述为基本事实。这些事实如果分割为再小的事实就会丢失信息。
简单事实的一些例子包括：
· 人有电话
· 人住在某个地方
· 人生于某个日期
· 人在某个日期被雇佣
这些事实相应的ORM模型如下：
图 1. 对象角色模型
图中的圆代表对象；矩形代表论断。在ORM中，象在逻辑中一样，一个论断只是带有对象洞的语句。箭头和点代表系统中的约束。
例如，在 "人有电话 "这个事实的诊断上的箭头可以翻译为：
有可能某个人有多于一个电话，并且至少有一个人有电话。
在 "人生于某个日期 "这个事实中，在论断上的箭头与连接对象与论断的点的结合表明：
每个人确切地出生于一个日期。
与 ER的比较
实体关系（ER）是另一种类型的数据库建模。ORM模型的简单性与ER相应部分的比较：
图 2. 实体关系
ORM以简单对象和论断的形式描述企业事实，而实体关系方法论以术语实体（拥有属性并参与关系）描述世界。在图1的ORM例子中，人，电话，地址和日期都表示为扮演有相互联系的角色的对象。在ER例子中，人是一个实体，它由属性：地址和电话进行描述。
例如，如果要把地址分解为街道，城市，州，ZIP码，那么必须把地址改变为具有相应属性的实体类型，结果会改变人与地址间的关系。尽管在上面的ORM模型中表示的约束也可以在ER中表示，但只要向模型中增加节点，或编写应用程序代码对模型进行补充，就可以表示其它约束。
ORM的优点
ORM提供的不只是描述不同对象间关系的一个简单而直接的方式。从示例中，可以看出ORM还提供了灵活性。使用ORM创建的模型比使用其它方法创建的模型更有能力适应系统的变化。另外，ORM允许非技术企业专家按样本数据谈论模型，因此他们可以使用真实世界的数据验证模型。因为ORM允许重用对象，数据模型能自动映射到正确标准化的数据库结构。
ORM模型的简单性简化了数据库查询过程。使用ORM查询工具，用户可以访问期望数据，而不必理解数据库的底层结构。
数据库生成和遍历引挚
象所有优秀的模型方法一样，ORM也不只是一个概念。它包含了不同的设计过程以帮助建模者映射概念的和逻辑的模型，或使用转换引挚在这些模型间转换。
ORM模型也能够自动地映射到大多数流行的关系型数据库所实现的数据库结构。检查前面的例子，ORM模型能自动生成ER图表或逻辑模型（可以翻译为SQL 代码，并适用于所选择的数据库）。
总结
利用非技术企业专家的知识对于确保应用程序满足企业需求是重要的。ORM，Visual Studio .NET的一个特性，是一个最初的、易于使用的概念性数据模型方法。通过使用不只是只有数据库专家才能理解的语言，ORM使那些充分理解了企业对应用程序需求的人能直接参与设计。
ORM还支持完全的遍历引挚，因此一旦定义了企业需求，它们就能迅速的转化为逻辑和物理数据库图表。使用ORM，组织可以提高应用程序开发的效率，确保企业需求能被正确交付。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- gameboy766
- (古巴)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- xiaotupansy
- (Pansy)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- gare1000
- (qq:270515011 弄个)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- coolbyefish
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- frank_lee_cn
- (Frank)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bonhomme
- 等 级：
dagecc的帖子内容翔实而丰富，但来源不一，里面很多概念和主张当然有道理。
但问题是dagecc展示的设计和代码和这些概念与主张之间有多少联系，我只好保留我的判断不作回答了，相信大家仁者见仁，智者见智。大家不妨仔细琢磨一下dagecc引用的“桥梁论”，一个值得考量的问题在于：一对一桥梁还是逻辑对物理的桥梁。
ORM的灵魂在于对关系的管理和映射，不是拿类去映射表关系，而是把类的关系映射为表关系。 这是许多人的主张，包括我本人。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- frank_lee_cn
- (Frank)
- 等 级：
是，你挺有见解的。
尤其是最后的那一句：ORM 的灵魂是把类的关系映射为表关系
我见到 dagecc 再跟他谈谈。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- frank_lee_cn
- (Frank)
- 等 级：
你提到的 一对一桥梁 还是 逻辑对物理桥梁，
不知道我有没有误解你的意思。
你说的是，dagecc 做的，是一对一的桥梁，即，一个表对象，有一个类对象来对应。
而你觉得，逻辑对物理的桥梁对应才是对的。
是这样子的意思吗﹖
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bonhomme
- 等 级：
再次感谢你对我的话题的兴趣。
关于我前帖中提到的“一对一 vs 逻辑对物理”这个问题：ORM应该使得程序员不但是用类来做数据库操作，而且要通过类来“思考”业务模型，或者换句话说，ORM要做的不是如何把数据库概念和行为映射为类和对象的概念和行为，而是把类和对象的概念和行为映射为数据库的概念和行为。这个话反正表达，实质含义有很大差别！
另外，我感觉 dagecc如果能举一个例子展示一下他们是如何实现我所展示的“厂家-客户-产品-订单”的例子，我认为更容易让大家理解他们的产品，以削除误解。最好，再加上一个“产品类别”(ProductCategory)的概念，要求是产品类别是树形的，允许任意明细的。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- frank_lee_cn
- (Frank)
- 等 级：
> 这个话反正表达，实质含义有很大差别！
是的，这个反正表达的部份，我理解。
> 通过类来“思考”业务模型
是的，这句话我同意。
> 另外，我感觉 dagecc 如果能举一个例子展示一下.....
我问过他，他当初贴帖回应的目的，就是为了能和你有些切磋、共同成长。
不过，因为他很少进来 CSDN，所以他留了 QQ 号希望能得到你的参与。
但很显然你比较喜欢在 CSDN 上谈，
所以你们对不上话。
没有关系，你当初贴帖的目的，我想
主要你想表达你对 ORM 的了解，分享给大家。
得到回应，我想你已经达到的目的。
dagecc 他的东西，是公司内产品，恐怕是不能再贴到这里来了。
而你的帖从一开始，就是以产品无关的角度来说明的，
我觉得这样子很好，
从观念上来理清ORM是什么，对我来说已经够了。
加上你提出了你对 dagecc ORM 的观点，
不管谁对谁错，
至少我知道你持的观点了。
dagecc 跟我谈了多次他的ORM产品，
我一直不太明白判断他的ORM好坏或对错的判断点是什么，
以至于一直没能给他好的建议。
你提你持的观点，让我一下子明白了许多。
我想dagecc提他观点的目的已经间接地达到了。
我在网上找到了一篇关于 ORM 的文章，
http://www.agiledata.org/essays/mappingObjects.html
原本看不太懂它的关键点，
有了你们这帖的讨论，
我一下子明白了这篇ORM的关键点。
因此，必须多谢你们的讨论，
我从中学习了不少。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bonhomme
- 等 级：
我不敢说dagecc的观点不对，因为他没有方便能在这里充分暴露他的观点，但对他已经提出的若干细节，我还是坦率地提出了我自己的不同见解。我只是在研究一点ORM的概念，dagecc走的比我远，因为他已经做出了产品了。
我的QQ是459561863，希望和你们二位成为朋友，并请转告dagecc，也许我是他的老乡。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- eastsun_genius
- (大漠狂沙)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- zj_fanyu
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- linlinselina
- 等 级：
2年以上相关工作经验.良好的教育背景.
有朋友CV请推荐:Selina@mst.com.cn
msn:lin830413@hotmail.com
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- iloveppmm
- (mmlover)
- 等 级：
找了N（多的我都记不清了）多的资料，都没有能解决我的疑问。都是擦边球。
这个 正中要害。
有了清醒的认识，再去学个ORM框架，想必事半功倍了。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- eshopbar2008
- (eshopbar2008)
- 等 级：
本人在项目实践中，总结出用hastable来保存实体对象属性与表字段的对应关系。欢迎讨论一下。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- JYYCOM
- (横眉冷对)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- ireenter
- (明振居士)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- shawn_yang
- (shawn)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
这使我想起了我早前写过的第一个ORM。那里，我给自己的第一位的要求是：自动适应版本升级。就是在数据库中有一个“版本号”，在代码中也有一个“版本号”，程序的各个类型的.cctor（静态初始化）方法中会去比较这个版本号，并且它会自动升级数据表（包括建表，删除过去有而现在没有的字段、索引、外键、过程等等，增加过去没有而现在新增的一切设置）。既然你已经在代码中使用Attribute标记出来了，那么你的程序员就不应该手动到数据库管理系统中去创建和修改数据库结构，全都由.net程序代劳了。
这样做，bonhomme 的意思就明白了。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
不要忘记，反射只需要进行一次，就缓冲在static变量中了。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
这个想法也可以算有楼主的想法的萌芽。不过.net对这类任务有着比“使用XML管理”更为专业的框架方法，其实就是楼主的“Attribute+反射”技术，可以直接拿来开发更为高级的功能，而不是停在研究底层技术上浪费时间。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- tabris17
- (四不象)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- flyingfz
- (戴眼镜的野人)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sun1976
- (嫁给我,你就是我的一妾)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- makecodeeasy
- (makecodeeasy)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- abcn
- (小宝,上酸菜)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- hanjoe109
- (子人★雪怡----了空★博天)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cooolchen
- (新的，一切都是新的。)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- yqyqyoyo
- (事物缥缈)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- chxljtt
- (浮云何时飞)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cnapc
- (明月照大江)
- 等 级：
个人觉得保持一个干净简单的目标软件设计框架是应用ORM的前提,ORM的实现倒不是太复杂的事情
可以相互参考.net和Java的ORM实现,有助于理解ORM的构造是为什么
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- suinon
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- acqy
- (sunnychen.org)
- 等 级：
从分层角度考虑，领域层不应该考虑存储细节问题。在领域对象上设置“Table”、“PrimaryKey”等特性，事实上已经违背了这样的规律。
有兴趣的读者可以去比较一下Castle ActiveRecord以及NHibernate，虽然CA是建立在NHibernate之上，但意思完全不一样。
当然，也不是说NHibernate才是正道，如果项目规模不大，领域层对象关系不复杂的情况下，采用类似于Castle ActiveRecord这样的ORM或许更加轻便快捷。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cnapc
- (明月照大江)
- 等 级：
偶们没必要认为ORM就是DB的Administrator,该划分到DB层的实现,还是划分到DB层.
Table的结构/View/存储过程,本来就是DB和应用的接口
如果不使用ORM,现在的代码还不是一样要关联到数据库的细节?
如果偶们认为ORM是一个编程工具(的规范),是不是会好理解些?
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- acqy
- (sunnychen.org)
- 等 级：
ORM的引入正是为了在业务层（传统三层结构中的业务层）中屏蔽数据库（或者说是外部存储机制）的访问细节，使得业务层能够更加专注在解决业务问题上，而不是访问数据库上。相对较差的设计是，在业务层布满了繁杂的SQL或者存储过程的调用，此时当你的后台数据库有变更的时候，你将会被这一大堆SQL所困扰。在此，说相对较差的意思是，我们需要具体情况具体分析，加入系统本身就不大，那你引入ORM也没必要。如果系统对性能要求很高，那么还不如直接使用ADO。
从效果上来看，ORM确实是让我们少写许多代码。但ORM绝不仅仅是让我们少写些代码这样“肤浅”。这正如MVP模式一样，它使得应用系统的某个层能够更加独立（解耦）于其它层，这样才能使得应用系统更具备扩展性。ORM解决的是状态持久化问题，数据库是目前最为通用的数据保存机制，但对于对象状态的持久化，它不是唯一的机制。比如，对象完全可以在被序列化以后保存到XML文件中。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cnapc
- (明月照大江)
- 等 级：
不要将某些概念想的太复杂，它们的目的真的很简单呢？
ORM做解耦？代价就太大了。
数据库难道不包括XML数据库？
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cnapc
- (明月照大江)
- 等 级：
而是各人的表述概念可能有不一样,ORM的确是封装了数据后台
而它对于偶来说也的确是一个工具,不用自己封装不同的数据SQL代码,不用写烦人的某些很相像的代码...
事实上,偶自己做了个类似于Java中Persist概念的库,来处理这些问题
所以从俩个角度来说,全正确
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- acqy
- (sunnychen.org)
- 等 级：
我想说明的是，其实数据库概念很广泛，关系型数据库只不过是其中的一种。
你可以选择自己的SQL层而不使用任何ORM，完全取决于你自己。但是无论是你自己写的SQL层，还是ORM，都不得不承担同样一个责任，就是分层解耦。因为业务层是不可能去考虑持久化细节的。
ORM与SQL层还有个细节上的区别，就是O。ORM处理的是业务对象，SQL处理的是数据。你可以去了解一下，.NET中引入Typed Data Set的用意，就能了解到为什么我们需要更多的关注O。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- acqy
- (sunnychen.org)
- 等 级：
我想说明的是，其实数据库概念很广泛，关系型数据库只不过是其中的一种。
你可以选择自己的SQL层而不使用任何ORM，完全取决于你自己。但是无论是你自己写的SQL层，还是ORM，都不得不承担同样一个责任，就是分层解耦。因为业务层是不可能去考虑持久化细节的。
ORM与SQL层还有个细节上的区别，就是O。ORM处理的是业务对象，SQL处理的是数据。你可以去了解一下，.NET中引入Typed Data Set的用意，就能了解到为什么我们需要更多的关注O。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cnapc
- (明月照大江)
- 等 级：
解耦对于大多数系统来说是必要的
同样对于IDE或语言也是一样,它们也有客户就是开发者,它们同样需要解耦,分层/封装不同的逻辑和实现
如果他们如同偶做出的软件,笨重而又繁琐,大概也不会有多少人使用了...
偶觉得啊,ORM处理的不能够是业务对象,只能是数据对象,如同Java中的实体Bean,这样也许就是你开始说的
NHibernate的轻便快捷?
偶只是将数据对象通过ORM和后台数据作映射(关系也好,存储也好),
而数据之间的存储关系是有穷的,完全可以通过某些表达式来表述.
而逻辑关系应该不会有什么样的东东能够完全涵盖,如果有那一定是AI了
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- acqy
- (sunnychen.org)
- 等 级：
个人认为，ORM的任务就是在业务层“不知道持久化机制是什么、如何工作”的情况下，维持业务对象的“持久化”状态。当业务对象需要持久化时，ORM完成持久化；当业务对象需要从持久化机制中重建时，ORM重建对象。
Hibernate这一词感觉也很有用意：（业务对象的）冬眠，明确说明了持久化这一状态。
当然，我还是坚持具体情况具体分析。不是所有的应用需要ORM。ORM至少会要付出性能代价，是否采用ORM应该要根据应用的规模以及其它的非业务性需求。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- michael_jiwei
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- isline
- (Aicken)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- microtry
- (编程就是照猫画虎)
- 等 级：
而功能界面确实各个独立的模块和权限管理;
并且,一个订单业务的来源和目标都有可能是不同的组织机构,
再则,不同的角色对数据的操作方式和输出方式是千差万别的,
比如,应用程序提供的搜索引擎输入"张三",你将要提供关于张三的所有类型的订单索引,然后由用户选择以后再进入精确处理模式,
那种基于CURD和数据驱动思想的方法将会使项目根本经不起需求的风吹草动,更不要说促进用户发展了
- patrickpan
- (离别钩)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bonhomme
- 等 级：
另外你说的从DataGrid直接提交对实体对象的更改，好像和ORM本身没有直接联系，而且在数据访问层理关照UI的实现，从一般的架构原则看，似乎欠妥。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- lingshixiao
- (★圣殿骑士)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dagecc01
- 等 级：
关系管理,你说的应该是数据库表格的关系吧.
在C#代码里,我专门定义了
表格标签TableAttribute,
视图标签ViewAttribute,
存储过程标签ProcessAttribute,
函数标签FunctionAttribute
主键标签PrimaryAttribute
外键标签ForeignAttribute
列标签ColumnAttribute
表与表间的关系,在早期的版本中,是通过ForeignAttribute来标注的.
现在是通过实体类的组合来实现的.
[ORMCombination( "productInfo.productInfoType InnerJoin productTypeInfo.productinfotypeID ")]//如果采用不含形参的ORMCombination,系统会自动根据表格的外键信息来关联.
public class TestReport
{
public productInfo;
public productTypeInfo;
.......
}
------------------
另外,我这套不仅仅只是ORM的功能,还包括数据访问,AOP,IoC,日志,异常,缓存,安全与授权,简单工作流等组件,如果说有个实体类的容器,那加强这个实体类容器的功能是一件有必要的事.这正好符合我们的目的:快速开发ERP,敏捷反应客户的需求.
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dagecc01
- 等 级：
6月后,组件库会发布一个版本,开发会暂停.
8月后,我们研发组会转入图形学,唉.头大.
希望在未结束之前把东西做的更好.希望能在大家身上多学点知识.
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bonhomme
- 等 级：
我的肤浅感觉：你的东西与其说是ORM（对象关系映射），不如说是ROM（关系对象映射），或者叫DOM（DB object mapping，数据库对象映射），也就是说你的是以数据库为出发点，力求在C#对象中“一对一”映射“各种”“物理的”“数据库实现”概念，例如你说的表、视图、存储过程、函数、主键、外键等，奥，对了，你还缺了触发器，是写帖子的时候忘记列出来了吧？
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- friky
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dagecc01
- 等 级：
我的肤浅感觉：你的东西与其说是ORM（对象关系映射），不如说是ROM（关系对象映射），或者叫DOM（DB object mapping，数据库对象映射），也就是说你的是以数据库为出发点，力求在C#对象中“一对一”映射“各种”“物理的”“数据库实现”概念，例如你说的表、视图、存储过程、函数、主键、外键等，奥，对了，你还缺了触发器，是写帖子的时候忘记列出来了吧？
=======================================
to bonhomme;
下面是来自: http://www.javaref.cn/topics/Hibernate/1458.html 的一段话:
-----------------------------------------------------------
2、什么是ORM？
ORM（Object-Relation
Mapping）是对象-关系映射，当下流行的开发语言都是面向对象的，如Java，C#。而当下流行的DB大多都是面向关系的，也就是关系数据库。这样在面向对象与面向关系之间需要一个桥梁，才能使二者协同无缝联合工作，ORM就是这个桥梁。映射关系如下：
[类] <=> [表]
[对象实例] <=> [表的行]
[属性] <=> [表的列]
那么这些映射关系是如何制定的呢？——只需要一个映射文件（XML）即可，在其中配置持久化类与DB表的映射关系后，ORM中间件在运行时参照此文件内容，对象持久化的DB中或把DB中数据加载到持久化类中。
Hibernate就是一个卓越的ORM中间件。
-----------------------------------------------------------
他说的很简明: 面向对象语言要与关系数据库之间有个桥梁.
只要做到了这点,就可以算是ORM.
ORM本来就是以数据库为出发点,为的就是要解决OO与关系数据库的映射.让程序员去少写SQL语句.
写在string 里的SQL语句,在编译的时候是无法发现错误的.更改了数据库的字段名称,就算现在的IDE有重构,但是你要重构字符串,那也是一个噩梦,他会把一些不需要重构的字符串也替换掉.
为什么要有函数和存储过程,这个是为了用户更加方便的调用.有很多老的系统,里面存在大量的存储过程和函数,新的系统要使用老的数据库,支持函数和存储过程,我认为是很有必要的.
为什么没有触发器,嘿嘿,我不喜欢这个东西,所以就没有.很多ORM还不支持存储过程和函数呢.
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dagecc01
- 等 级：
15、什么是ORM？常用的ORM架构有哪几种？
ORM是对象关系映射（object relation mapping) 。一种将关系型数据转化城面向对象数据进行处理的过程。就是为了不让在逻辑层看到大量的SQL语句。将关系型数据库中的数据（往往妨在表中）采用一种映射mapping，（通过XML文件的方式），转换成直接用面向对象的语言去操作，这样就可以避免使用SQL . 常用的ORM框架有：java中hibernate。.net中的nhibernate和grove 。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dagecc01
- 等 级：
什么是ORM?
对象角色建模（ORM）提供了概念性的、易于理解的模型化数据的方法。ORM方法论基于三个核心原则：
· 简单。以最基本的形式建模数据。
· 传达性。数据库结构被任何人都能理解的语言文档化。
· 精确性。基于数据模型创建正确标准化了的结构。
典型地，建模者通过收集来自那些熟悉应用程序但不熟练的数据建模者的人的信息开发信息模型。建模者必须能够用非技术企业专家可以理解的术语在概念层次上与数据结构进行通讯。建模者也必须能以简单的单元分析信息，对样本数据进行处理。ORM专门被设计为改进这种联系。
规则表达式
ORM把应用程序世界表示为具有角色（关系中的部分）的一组对象（实体或值）。ORM有时也称为基于事实的建模，因为它把相关数据描述为基本事实。这些事实如果分割为再小的事实就会丢失信息。
简单事实的一些例子包括：
· 人有电话
· 人住在某个地方
· 人生于某个日期
· 人在某个日期被雇佣
这些事实相应的ORM模型如下：
图 1. 对象角色模型
图中的圆代表对象；矩形代表论断。在ORM中，象在逻辑中一样，一个论断只是带有对象洞的语句。箭头和点代表系统中的约束。
例如，在 "人有电话 "这个事实的诊断上的箭头可以翻译为：
有可能某个人有多于一个电话，并且至少有一个人有电话。
在 "人生于某个日期 "这个事实中，在论断上的箭头与连接对象与论断的点的结合表明：
每个人确切地出生于一个日期。
与 ER的比较
实体关系（ER）是另一种类型的数据库建模。ORM模型的简单性与ER相应部分的比较：
图 2. 实体关系
ORM以简单对象和论断的形式描述企业事实，而实体关系方法论以术语实体（拥有属性并参与关系）描述世界。在图1的ORM例子中，人，电话，地址和日期都表示为扮演有相互联系的角色的对象。在ER例子中，人是一个实体，它由属性：地址和电话进行描述。
例如，如果要把地址分解为街道，城市，州，ZIP码，那么必须把地址改变为具有相应属性的实体类型，结果会改变人与地址间的关系。尽管在上面的ORM模型中表示的约束也可以在ER中表示，但只要向模型中增加节点，或编写应用程序代码对模型进行补充，就可以表示其它约束。
ORM的优点
ORM提供的不只是描述不同对象间关系的一个简单而直接的方式。从示例中，可以看出ORM还提供了灵活性。使用ORM创建的模型比使用其它方法创建的模型更有能力适应系统的变化。另外，ORM允许非技术企业专家按样本数据谈论模型，因此他们可以使用真实世界的数据验证模型。因为ORM允许重用对象，数据模型能自动映射到正确标准化的数据库结构。
ORM模型的简单性简化了数据库查询过程。使用ORM查询工具，用户可以访问期望数据，而不必理解数据库的底层结构。
数据库生成和遍历引挚
象所有优秀的模型方法一样，ORM也不只是一个概念。它包含了不同的设计过程以帮助建模者映射概念的和逻辑的模型，或使用转换引挚在这些模型间转换。
ORM模型也能够自动地映射到大多数流行的关系型数据库所实现的数据库结构。检查前面的例子，ORM模型能自动生成ER图表或逻辑模型（可以翻译为SQL 代码，并适用于所选择的数据库）。
总结
利用非技术企业专家的知识对于确保应用程序满足企业需求是重要的。ORM，Visual Studio .NET的一个特性，是一个最初的、易于使用的概念性数据模型方法。通过使用不只是只有数据库专家才能理解的语言，ORM使那些充分理解了企业对应用程序需求的人能直接参与设计。
ORM还支持完全的遍历引挚，因此一旦定义了企业需求，它们就能迅速的转化为逻辑和物理数据库图表。使用ORM，组织可以提高应用程序开发的效率，确保企业需求能被正确交付。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- gameboy766
- (古巴)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- xiaotupansy
- (Pansy)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- gare1000
- (qq:270515011 弄个)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- coolbyefish
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- frank_lee_cn
- (Frank)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bonhomme
- 等 级：
dagecc的帖子内容翔实而丰富，但来源不一，里面很多概念和主张当然有道理。
但问题是dagecc展示的设计和代码和这些概念与主张之间有多少联系，我只好保留我的判断不作回答了，相信大家仁者见仁，智者见智。大家不妨仔细琢磨一下dagecc引用的“桥梁论”，一个值得考量的问题在于：一对一桥梁还是逻辑对物理的桥梁。
ORM的灵魂在于对关系的管理和映射，不是拿类去映射表关系，而是把类的关系映射为表关系。 这是许多人的主张，包括我本人。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- frank_lee_cn
- (Frank)
- 等 级：
是，你挺有见解的。
尤其是最后的那一句：ORM 的灵魂是把类的关系映射为表关系
我见到 dagecc 再跟他谈谈。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- frank_lee_cn
- (Frank)
- 等 级：
你提到的 一对一桥梁 还是 逻辑对物理桥梁，
不知道我有没有误解你的意思。
你说的是，dagecc 做的，是一对一的桥梁，即，一个表对象，有一个类对象来对应。
而你觉得，逻辑对物理的桥梁对应才是对的。
是这样子的意思吗﹖
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bonhomme
- 等 级：
再次感谢你对我的话题的兴趣。
关于我前帖中提到的“一对一 vs 逻辑对物理”这个问题：ORM应该使得程序员不但是用类来做数据库操作，而且要通过类来“思考”业务模型，或者换句话说，ORM要做的不是如何把数据库概念和行为映射为类和对象的概念和行为，而是把类和对象的概念和行为映射为数据库的概念和行为。这个话反正表达，实质含义有很大差别！
另外，我感觉 dagecc如果能举一个例子展示一下他们是如何实现我所展示的“厂家-客户-产品-订单”的例子，我认为更容易让大家理解他们的产品，以削除误解。最好，再加上一个“产品类别”(ProductCategory)的概念，要求是产品类别是树形的，允许任意明细的。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- frank_lee_cn
- (Frank)
- 等 级：
> 这个话反正表达，实质含义有很大差别！
是的，这个反正表达的部份，我理解。
> 通过类来“思考”业务模型
是的，这句话我同意。
> 另外，我感觉 dagecc 如果能举一个例子展示一下.....
我问过他，他当初贴帖回应的目的，就是为了能和你有些切磋、共同成长。
不过，因为他很少进来 CSDN，所以他留了 QQ 号希望能得到你的参与。
但很显然你比较喜欢在 CSDN 上谈，
所以你们对不上话。
没有关系，你当初贴帖的目的，我想
主要你想表达你对 ORM 的了解，分享给大家。
得到回应，我想你已经达到的目的。
dagecc 他的东西，是公司内产品，恐怕是不能再贴到这里来了。
而你的帖从一开始，就是以产品无关的角度来说明的，
我觉得这样子很好，
从观念上来理清ORM是什么，对我来说已经够了。
加上你提出了你对 dagecc ORM 的观点，
不管谁对谁错，
至少我知道你持的观点了。
dagecc 跟我谈了多次他的ORM产品，
我一直不太明白判断他的ORM好坏或对错的判断点是什么，
以至于一直没能给他好的建议。
你提你持的观点，让我一下子明白了许多。
我想dagecc提他观点的目的已经间接地达到了。
我在网上找到了一篇关于 ORM 的文章，
http://www.agiledata.org/essays/mappingObjects.html
原本看不太懂它的关键点，
有了你们这帖的讨论，
我一下子明白了这篇ORM的关键点。
因此，必须多谢你们的讨论，
我从中学习了不少。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bonhomme
- 等 级：
我不敢说dagecc的观点不对，因为他没有方便能在这里充分暴露他的观点，但对他已经提出的若干细节，我还是坦率地提出了我自己的不同见解。我只是在研究一点ORM的概念，dagecc走的比我远，因为他已经做出了产品了。
我的QQ是459561863，希望和你们二位成为朋友，并请转告dagecc，也许我是他的老乡。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- eastsun_genius
- (大漠狂沙)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- zj_fanyu
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- linlinselina
- 等 级：
2年以上相关工作经验.良好的教育背景.
有朋友CV请推荐:Selina@mst.com.cn
msn:lin830413@hotmail.com
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- iloveppmm
- (mmlover)
- 等 级：
找了N（多的我都记不清了）多的资料，都没有能解决我的疑问。都是擦边球。
这个 正中要害。
有了清醒的认识，再去学个ORM框架，想必事半功倍了。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- eshopbar2008
- (eshopbar2008)
- 等 级：
本人在项目实践中，总结出用hastable来保存实体对象属性与表字段的对应关系。欢迎讨论一下。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- JYYCOM
- (横眉冷对)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- ireenter
- (明振居士)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- shawn_yang
- (shawn)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
这使我想起了我早前写过的第一个ORM。那里，我给自己的第一位的要求是：自动适应版本升级。就是在数据库中有一个“版本号”，在代码中也有一个“版本号”，程序的各个类型的.cctor（静态初始化）方法中会去比较这个版本号，并且它会自动升级数据表（包括建表，删除过去有而现在没有的字段、索引、外键、过程等等，增加过去没有而现在新增的一切设置）。既然你已经在代码中使用Attribute标记出来了，那么你的程序员就不应该手动到数据库管理系统中去创建和修改数据库结构，全都由.net程序代劳了。
这样做，bonhomme 的意思就明白了。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
不要忘记，反射只需要进行一次，就缓冲在static变量中了。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
这个想法也可以算有楼主的想法的萌芽。不过.net对这类任务有着比“使用XML管理”更为专业的框架方法，其实就是楼主的“Attribute+反射”技术，可以直接拿来开发更为高级的功能，而不是停在研究底层技术上浪费时间。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- tabris17
- (四不象)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- flyingfz
- (戴眼镜的野人)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sun1976
- (嫁给我,你就是我的一妾)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- makecodeeasy
- (makecodeeasy)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- abcn
- (小宝,上酸菜)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- hanjoe109
- (子人★雪怡----了空★博天)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cooolchen
- (新的，一切都是新的。)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- yqyqyoyo
- (事物缥缈)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- chxljtt
- (浮云何时飞)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cnapc
- (明月照大江)
- 等 级：
个人觉得保持一个干净简单的目标软件设计框架是应用ORM的前提,ORM的实现倒不是太复杂的事情
可以相互参考.net和Java的ORM实现,有助于理解ORM的构造是为什么
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- suinon
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- acqy
- (sunnychen.org)
- 等 级：
从分层角度考虑，领域层不应该考虑存储细节问题。在领域对象上设置“Table”、“PrimaryKey”等特性，事实上已经违背了这样的规律。
有兴趣的读者可以去比较一下Castle ActiveRecord以及NHibernate，虽然CA是建立在NHibernate之上，但意思完全不一样。
当然，也不是说NHibernate才是正道，如果项目规模不大，领域层对象关系不复杂的情况下，采用类似于Castle ActiveRecord这样的ORM或许更加轻便快捷。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cnapc
- (明月照大江)
- 等 级：
偶们没必要认为ORM就是DB的Administrator,该划分到DB层的实现,还是划分到DB层.
Table的结构/View/存储过程,本来就是DB和应用的接口
如果不使用ORM,现在的代码还不是一样要关联到数据库的细节?
如果偶们认为ORM是一个编程工具(的规范),是不是会好理解些?
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- acqy
- (sunnychen.org)
- 等 级：
ORM的引入正是为了在业务层（传统三层结构中的业务层）中屏蔽数据库（或者说是外部存储机制）的访问细节，使得业务层能够更加专注在解决业务问题上，而不是访问数据库上。相对较差的设计是，在业务层布满了繁杂的SQL或者存储过程的调用，此时当你的后台数据库有变更的时候，你将会被这一大堆SQL所困扰。在此，说相对较差的意思是，我们需要具体情况具体分析，加入系统本身就不大，那你引入ORM也没必要。如果系统对性能要求很高，那么还不如直接使用ADO。
从效果上来看，ORM确实是让我们少写许多代码。但ORM绝不仅仅是让我们少写些代码这样“肤浅”。这正如MVP模式一样，它使得应用系统的某个层能够更加独立（解耦）于其它层，这样才能使得应用系统更具备扩展性。ORM解决的是状态持久化问题，数据库是目前最为通用的数据保存机制，但对于对象状态的持久化，它不是唯一的机制。比如，对象完全可以在被序列化以后保存到XML文件中。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cnapc
- (明月照大江)
- 等 级：
不要将某些概念想的太复杂，它们的目的真的很简单呢？
ORM做解耦？代价就太大了。
数据库难道不包括XML数据库？
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cnapc
- (明月照大江)
- 等 级：
而是各人的表述概念可能有不一样,ORM的确是封装了数据后台
而它对于偶来说也的确是一个工具,不用自己封装不同的数据SQL代码,不用写烦人的某些很相像的代码...
事实上,偶自己做了个类似于Java中Persist概念的库,来处理这些问题
所以从俩个角度来说,全正确
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- acqy
- (sunnychen.org)
- 等 级：
我想说明的是，其实数据库概念很广泛，关系型数据库只不过是其中的一种。
你可以选择自己的SQL层而不使用任何ORM，完全取决于你自己。但是无论是你自己写的SQL层，还是ORM，都不得不承担同样一个责任，就是分层解耦。因为业务层是不可能去考虑持久化细节的。
ORM与SQL层还有个细节上的区别，就是O。ORM处理的是业务对象，SQL处理的是数据。你可以去了解一下，.NET中引入Typed Data Set的用意，就能了解到为什么我们需要更多的关注O。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- acqy
- (sunnychen.org)
- 等 级：
我想说明的是，其实数据库概念很广泛，关系型数据库只不过是其中的一种。
你可以选择自己的SQL层而不使用任何ORM，完全取决于你自己。但是无论是你自己写的SQL层，还是ORM，都不得不承担同样一个责任，就是分层解耦。因为业务层是不可能去考虑持久化细节的。
ORM与SQL层还有个细节上的区别，就是O。ORM处理的是业务对象，SQL处理的是数据。你可以去了解一下，.NET中引入Typed Data Set的用意，就能了解到为什么我们需要更多的关注O。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cnapc
- (明月照大江)
- 等 级：
解耦对于大多数系统来说是必要的
同样对于IDE或语言也是一样,它们也有客户就是开发者,它们同样需要解耦,分层/封装不同的逻辑和实现
如果他们如同偶做出的软件,笨重而又繁琐,大概也不会有多少人使用了...
偶觉得啊,ORM处理的不能够是业务对象,只能是数据对象,如同Java中的实体Bean,这样也许就是你开始说的
NHibernate的轻便快捷?
偶只是将数据对象通过ORM和后台数据作映射(关系也好,存储也好),
而数据之间的存储关系是有穷的,完全可以通过某些表达式来表述.
而逻辑关系应该不会有什么样的东东能够完全涵盖,如果有那一定是AI了
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- acqy
- (sunnychen.org)
- 等 级：
个人认为，ORM的任务就是在业务层“不知道持久化机制是什么、如何工作”的情况下，维持业务对象的“持久化”状态。当业务对象需要持久化时，ORM完成持久化；当业务对象需要从持久化机制中重建时，ORM重建对象。
Hibernate这一词感觉也很有用意：（业务对象的）冬眠，明确说明了持久化这一状态。
当然，我还是坚持具体情况具体分析。不是所有的应用需要ORM。ORM至少会要付出性能代价，是否采用ORM应该要根据应用的规模以及其它的非业务性需求。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- michael_jiwei
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- isline
- (Aicken)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- microtry
- (编程就是照猫画虎)
- 等 级：
而功能界面确实各个独立的模块和权限管理;
并且,一个订单业务的来源和目标都有可能是不同的组织机构,
再则,不同的角色对数据的操作方式和输出方式是千差万别的,
比如,应用程序提供的搜索引擎输入"张三",你将要提供关于张三的所有类型的订单索引,然后由用户选择以后再进入精确处理模式,
那种基于CURD和数据驱动思想的方法将会使项目根本经不起需求的风吹草动,更不要说促进用户发展了好文，谢谢LZ
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bonhomme
- 等 级：
另外你说的从DataGrid直接提交对实体对象的更改，好像和ORM本身没有直接联系，而且在数据访问层理关照UI的实现，从一般的架构原则看，似乎欠妥。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- lingshixiao
- (★圣殿骑士)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dagecc01
- 等 级：
关系管理,你说的应该是数据库表格的关系吧.
在C#代码里,我专门定义了
表格标签TableAttribute,
视图标签ViewAttribute,
存储过程标签ProcessAttribute,
函数标签FunctionAttribute
主键标签PrimaryAttribute
外键标签ForeignAttribute
列标签ColumnAttribute
表与表间的关系,在早期的版本中,是通过ForeignAttribute来标注的.
现在是通过实体类的组合来实现的.
[ORMCombination( "productInfo.productInfoType InnerJoin productTypeInfo.productinfotypeID ")]//如果采用不含形参的ORMCombination,系统会自动根据表格的外键信息来关联.
public class TestReport
{
public productInfo;
public productTypeInfo;
.......
}
------------------
另外,我这套不仅仅只是ORM的功能,还包括数据访问,AOP,IoC,日志,异常,缓存,安全与授权,简单工作流等组件,如果说有个实体类的容器,那加强这个实体类容器的功能是一件有必要的事.这正好符合我们的目的:快速开发ERP,敏捷反应客户的需求.
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dagecc01
- 等 级：
6月后,组件库会发布一个版本,开发会暂停.
8月后,我们研发组会转入图形学,唉.头大.
希望在未结束之前把东西做的更好.希望能在大家身上多学点知识.
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bonhomme
- 等 级：
我的肤浅感觉：你的东西与其说是ORM（对象关系映射），不如说是ROM（关系对象映射），或者叫DOM（DB object mapping，数据库对象映射），也就是说你的是以数据库为出发点，力求在C#对象中“一对一”映射“各种”“物理的”“数据库实现”概念，例如你说的表、视图、存储过程、函数、主键、外键等，奥，对了，你还缺了触发器，是写帖子的时候忘记列出来了吧？
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- friky
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dagecc01
- 等 级：
我的肤浅感觉：你的东西与其说是ORM（对象关系映射），不如说是ROM（关系对象映射），或者叫DOM（DB object mapping，数据库对象映射），也就是说你的是以数据库为出发点，力求在C#对象中“一对一”映射“各种”“物理的”“数据库实现”概念，例如你说的表、视图、存储过程、函数、主键、外键等，奥，对了，你还缺了触发器，是写帖子的时候忘记列出来了吧？
=======================================
to bonhomme;
下面是来自: http://www.javaref.cn/topics/Hibernate/1458.html 的一段话:
-----------------------------------------------------------
2、什么是ORM？
ORM（Object-Relation
Mapping）是对象-关系映射，当下流行的开发语言都是面向对象的，如Java，C#。而当下流行的DB大多都是面向关系的，也就是关系数据库。这样在面向对象与面向关系之间需要一个桥梁，才能使二者协同无缝联合工作，ORM就是这个桥梁。映射关系如下：
[类] <=> [表]
[对象实例] <=> [表的行]
[属性] <=> [表的列]
那么这些映射关系是如何制定的呢？——只需要一个映射文件（XML）即可，在其中配置持久化类与DB表的映射关系后，ORM中间件在运行时参照此文件内容，对象持久化的DB中或把DB中数据加载到持久化类中。
Hibernate就是一个卓越的ORM中间件。
-----------------------------------------------------------
他说的很简明: 面向对象语言要与关系数据库之间有个桥梁.
只要做到了这点,就可以算是ORM.
ORM本来就是以数据库为出发点,为的就是要解决OO与关系数据库的映射.让程序员去少写SQL语句.
写在string 里的SQL语句,在编译的时候是无法发现错误的.更改了数据库的字段名称,就算现在的IDE有重构,但是你要重构字符串,那也是一个噩梦,他会把一些不需要重构的字符串也替换掉.
为什么要有函数和存储过程,这个是为了用户更加方便的调用.有很多老的系统,里面存在大量的存储过程和函数,新的系统要使用老的数据库,支持函数和存储过程,我认为是很有必要的.
为什么没有触发器,嘿嘿,我不喜欢这个东西,所以就没有.很多ORM还不支持存储过程和函数呢.
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dagecc01
- 等 级：
15、什么是ORM？常用的ORM架构有哪几种？
ORM是对象关系映射（object relation mapping) 。一种将关系型数据转化城面向对象数据进行处理的过程。就是为了不让在逻辑层看到大量的SQL语句。将关系型数据库中的数据（往往妨在表中）采用一种映射mapping，（通过XML文件的方式），转换成直接用面向对象的语言去操作，这样就可以避免使用SQL . 常用的ORM框架有：java中hibernate。.net中的nhibernate和grove 。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dagecc01
- 等 级：
什么是ORM?
对象角色建模（ORM）提供了概念性的、易于理解的模型化数据的方法。ORM方法论基于三个核心原则：
· 简单。以最基本的形式建模数据。
· 传达性。数据库结构被任何人都能理解的语言文档化。
· 精确性。基于数据模型创建正确标准化了的结构。
典型地，建模者通过收集来自那些熟悉应用程序但不熟练的数据建模者的人的信息开发信息模型。建模者必须能够用非技术企业专家可以理解的术语在概念层次上与数据结构进行通讯。建模者也必须能以简单的单元分析信息，对样本数据进行处理。ORM专门被设计为改进这种联系。
规则表达式
ORM把应用程序世界表示为具有角色（关系中的部分）的一组对象（实体或值）。ORM有时也称为基于事实的建模，因为它把相关数据描述为基本事实。这些事实如果分割为再小的事实就会丢失信息。
简单事实的一些例子包括：
· 人有电话
· 人住在某个地方
· 人生于某个日期
· 人在某个日期被雇佣
这些事实相应的ORM模型如下：
图 1. 对象角色模型
图中的圆代表对象；矩形代表论断。在ORM中，象在逻辑中一样，一个论断只是带有对象洞的语句。箭头和点代表系统中的约束。
例如，在 "人有电话 "这个事实的诊断上的箭头可以翻译为：
有可能某个人有多于一个电话，并且至少有一个人有电话。
在 "人生于某个日期 "这个事实中，在论断上的箭头与连接对象与论断的点的结合表明：
每个人确切地出生于一个日期。
与 ER的比较
实体关系（ER）是另一种类型的数据库建模。ORM模型的简单性与ER相应部分的比较：
图 2. 实体关系
ORM以简单对象和论断的形式描述企业事实，而实体关系方法论以术语实体（拥有属性并参与关系）描述世界。在图1的ORM例子中，人，电话，地址和日期都表示为扮演有相互联系的角色的对象。在ER例子中，人是一个实体，它由属性：地址和电话进行描述。
例如，如果要把地址分解为街道，城市，州，ZIP码，那么必须把地址改变为具有相应属性的实体类型，结果会改变人与地址间的关系。尽管在上面的ORM模型中表示的约束也可以在ER中表示，但只要向模型中增加节点，或编写应用程序代码对模型进行补充，就可以表示其它约束。
ORM的优点
ORM提供的不只是描述不同对象间关系的一个简单而直接的方式。从示例中，可以看出ORM还提供了灵活性。使用ORM创建的模型比使用其它方法创建的模型更有能力适应系统的变化。另外，ORM允许非技术企业专家按样本数据谈论模型，因此他们可以使用真实世界的数据验证模型。因为ORM允许重用对象，数据模型能自动映射到正确标准化的数据库结构。
ORM模型的简单性简化了数据库查询过程。使用ORM查询工具，用户可以访问期望数据，而不必理解数据库的底层结构。
数据库生成和遍历引挚
象所有优秀的模型方法一样，ORM也不只是一个概念。它包含了不同的设计过程以帮助建模者映射概念的和逻辑的模型，或使用转换引挚在这些模型间转换。
ORM模型也能够自动地映射到大多数流行的关系型数据库所实现的数据库结构。检查前面的例子，ORM模型能自动生成ER图表或逻辑模型（可以翻译为SQL 代码，并适用于所选择的数据库）。
总结
利用非技术企业专家的知识对于确保应用程序满足企业需求是重要的。ORM，Visual Studio .NET的一个特性，是一个最初的、易于使用的概念性数据模型方法。通过使用不只是只有数据库专家才能理解的语言，ORM使那些充分理解了企业对应用程序需求的人能直接参与设计。
ORM还支持完全的遍历引挚，因此一旦定义了企业需求，它们就能迅速的转化为逻辑和物理数据库图表。使用ORM，组织可以提高应用程序开发的效率，确保企业需求能被正确交付。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- gameboy766
- (古巴)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- xiaotupansy
- (Pansy)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- gare1000
- (qq:270515011 弄个)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- coolbyefish
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- frank_lee_cn
- (Frank)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bonhomme
- 等 级：
dagecc的帖子内容翔实而丰富，但来源不一，里面很多概念和主张当然有道理。
但问题是dagecc展示的设计和代码和这些概念与主张之间有多少联系，我只好保留我的判断不作回答了，相信大家仁者见仁，智者见智。大家不妨仔细琢磨一下dagecc引用的“桥梁论”，一个值得考量的问题在于：一对一桥梁还是逻辑对物理的桥梁。
ORM的灵魂在于对关系的管理和映射，不是拿类去映射表关系，而是把类的关系映射为表关系。 这是许多人的主张，包括我本人。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- frank_lee_cn
- (Frank)
- 等 级：
是，你挺有见解的。
尤其是最后的那一句：ORM 的灵魂是把类的关系映射为表关系
我见到 dagecc 再跟他谈谈。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- frank_lee_cn
- (Frank)
- 等 级：
你提到的 一对一桥梁 还是 逻辑对物理桥梁，
不知道我有没有误解你的意思。
你说的是，dagecc 做的，是一对一的桥梁，即，一个表对象，有一个类对象来对应。
而你觉得，逻辑对物理的桥梁对应才是对的。
是这样子的意思吗﹖
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bonhomme
- 等 级：
再次感谢你对我的话题的兴趣。
关于我前帖中提到的“一对一 vs 逻辑对物理”这个问题：ORM应该使得程序员不但是用类来做数据库操作，而且要通过类来“思考”业务模型，或者换句话说，ORM要做的不是如何把数据库概念和行为映射为类和对象的概念和行为，而是把类和对象的概念和行为映射为数据库的概念和行为。这个话反正表达，实质含义有很大差别！
另外，我感觉 dagecc如果能举一个例子展示一下他们是如何实现我所展示的“厂家-客户-产品-订单”的例子，我认为更容易让大家理解他们的产品，以削除误解。最好，再加上一个“产品类别”(ProductCategory)的概念，要求是产品类别是树形的，允许任意明细的。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- frank_lee_cn
- (Frank)
- 等 级：
> 这个话反正表达，实质含义有很大差别！
是的，这个反正表达的部份，我理解。
> 通过类来“思考”业务模型
是的，这句话我同意。
> 另外，我感觉 dagecc 如果能举一个例子展示一下.....
我问过他，他当初贴帖回应的目的，就是为了能和你有些切磋、共同成长。
不过，因为他很少进来 CSDN，所以他留了 QQ 号希望能得到你的参与。
但很显然你比较喜欢在 CSDN 上谈，
所以你们对不上话。
没有关系，你当初贴帖的目的，我想
主要你想表达你对 ORM 的了解，分享给大家。
得到回应，我想你已经达到的目的。
dagecc 他的东西，是公司内产品，恐怕是不能再贴到这里来了。
而你的帖从一开始，就是以产品无关的角度来说明的，
我觉得这样子很好，
从观念上来理清ORM是什么，对我来说已经够了。
加上你提出了你对 dagecc ORM 的观点，
不管谁对谁错，
至少我知道你持的观点了。
dagecc 跟我谈了多次他的ORM产品，
我一直不太明白判断他的ORM好坏或对错的判断点是什么，
以至于一直没能给他好的建议。
你提你持的观点，让我一下子明白了许多。
我想dagecc提他观点的目的已经间接地达到了。
我在网上找到了一篇关于 ORM 的文章，
http://www.agiledata.org/essays/mappingObjects.html
原本看不太懂它的关键点，
有了你们这帖的讨论，
我一下子明白了这篇ORM的关键点。
因此，必须多谢你们的讨论，
我从中学习了不少。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bonhomme
- 等 级：
我不敢说dagecc的观点不对，因为他没有方便能在这里充分暴露他的观点，但对他已经提出的若干细节，我还是坦率地提出了我自己的不同见解。我只是在研究一点ORM的概念，dagecc走的比我远，因为他已经做出了产品了。
我的QQ是459561863，希望和你们二位成为朋友，并请转告dagecc，也许我是他的老乡。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- eastsun_genius
- (大漠狂沙)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- zj_fanyu
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- linlinselina
- 等 级：
2年以上相关工作经验.良好的教育背景.
有朋友CV请推荐:Selina@mst.com.cn
msn:lin830413@hotmail.com
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- iloveppmm
- (mmlover)
- 等 级：
找了N（多的我都记不清了）多的资料，都没有能解决我的疑问。都是擦边球。
这个 正中要害。
有了清醒的认识，再去学个ORM框架，想必事半功倍了。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- eshopbar2008
- (eshopbar2008)
- 等 级：
本人在项目实践中，总结出用hastable来保存实体对象属性与表字段的对应关系。欢迎讨论一下。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- JYYCOM
- (横眉冷对)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- ireenter
- (明振居士)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- shawn_yang
- (shawn)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
这使我想起了我早前写过的第一个ORM。那里，我给自己的第一位的要求是：自动适应版本升级。就是在数据库中有一个“版本号”，在代码中也有一个“版本号”，程序的各个类型的.cctor（静态初始化）方法中会去比较这个版本号，并且它会自动升级数据表（包括建表，删除过去有而现在没有的字段、索引、外键、过程等等，增加过去没有而现在新增的一切设置）。既然你已经在代码中使用Attribute标记出来了，那么你的程序员就不应该手动到数据库管理系统中去创建和修改数据库结构，全都由.net程序代劳了。
这样做，bonhomme 的意思就明白了。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
不要忘记，反射只需要进行一次，就缓冲在static变量中了。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
这个想法也可以算有楼主的想法的萌芽。不过.net对这类任务有着比“使用XML管理”更为专业的框架方法，其实就是楼主的“Attribute+反射”技术，可以直接拿来开发更为高级的功能，而不是停在研究底层技术上浪费时间。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- tabris17
- (四不象)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- flyingfz
- (戴眼镜的野人)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sun1976
- (嫁给我,你就是我的一妾)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- makecodeeasy
- (makecodeeasy)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- abcn
- (小宝,上酸菜)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- hanjoe109
- (子人★雪怡----了空★博天)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cooolchen
- (新的，一切都是新的。)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- yqyqyoyo
- (事物缥缈)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- chxljtt
- (浮云何时飞)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cnapc
- (明月照大江)
- 等 级：
个人觉得保持一个干净简单的目标软件设计框架是应用ORM的前提,ORM的实现倒不是太复杂的事情
可以相互参考.net和Java的ORM实现,有助于理解ORM的构造是为什么
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- suinon
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- acqy
- (sunnychen.org)
- 等 级：
从分层角度考虑，领域层不应该考虑存储细节问题。在领域对象上设置“Table”、“PrimaryKey”等特性，事实上已经违背了这样的规律。
有兴趣的读者可以去比较一下Castle ActiveRecord以及NHibernate，虽然CA是建立在NHibernate之上，但意思完全不一样。
当然，也不是说NHibernate才是正道，如果项目规模不大，领域层对象关系不复杂的情况下，采用类似于Castle ActiveRecord这样的ORM或许更加轻便快捷。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cnapc
- (明月照大江)
- 等 级：
偶们没必要认为ORM就是DB的Administrator,该划分到DB层的实现,还是划分到DB层.
Table的结构/View/存储过程,本来就是DB和应用的接口
如果不使用ORM,现在的代码还不是一样要关联到数据库的细节?
如果偶们认为ORM是一个编程工具(的规范),是不是会好理解些?
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- acqy
- (sunnychen.org)
- 等 级：
ORM的引入正是为了在业务层（传统三层结构中的业务层）中屏蔽数据库（或者说是外部存储机制）的访问细节，使得业务层能够更加专注在解决业务问题上，而不是访问数据库上。相对较差的设计是，在业务层布满了繁杂的SQL或者存储过程的调用，此时当你的后台数据库有变更的时候，你将会被这一大堆SQL所困扰。在此，说相对较差的意思是，我们需要具体情况具体分析，加入系统本身就不大，那你引入ORM也没必要。如果系统对性能要求很高，那么还不如直接使用ADO。
从效果上来看，ORM确实是让我们少写许多代码。但ORM绝不仅仅是让我们少写些代码这样“肤浅”。这正如MVP模式一样，它使得应用系统的某个层能够更加独立（解耦）于其它层，这样才能使得应用系统更具备扩展性。ORM解决的是状态持久化问题，数据库是目前最为通用的数据保存机制，但对于对象状态的持久化，它不是唯一的机制。比如，对象完全可以在被序列化以后保存到XML文件中。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cnapc
- (明月照大江)
- 等 级：
不要将某些概念想的太复杂，它们的目的真的很简单呢？
ORM做解耦？代价就太大了。
数据库难道不包括XML数据库？
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cnapc
- (明月照大江)
- 等 级：
而是各人的表述概念可能有不一样,ORM的确是封装了数据后台
而它对于偶来说也的确是一个工具,不用自己封装不同的数据SQL代码,不用写烦人的某些很相像的代码...
事实上,偶自己做了个类似于Java中Persist概念的库,来处理这些问题
所以从俩个角度来说,全正确
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- acqy
- (sunnychen.org)
- 等 级：
我想说明的是，其实数据库概念很广泛，关系型数据库只不过是其中的一种。
你可以选择自己的SQL层而不使用任何ORM，完全取决于你自己。但是无论是你自己写的SQL层，还是ORM，都不得不承担同样一个责任，就是分层解耦。因为业务层是不可能去考虑持久化细节的。
ORM与SQL层还有个细节上的区别，就是O。ORM处理的是业务对象，SQL处理的是数据。你可以去了解一下，.NET中引入Typed Data Set的用意，就能了解到为什么我们需要更多的关注O。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- acqy
- (sunnychen.org)
- 等 级：
我想说明的是，其实数据库概念很广泛，关系型数据库只不过是其中的一种。
你可以选择自己的SQL层而不使用任何ORM，完全取决于你自己。但是无论是你自己写的SQL层，还是ORM，都不得不承担同样一个责任，就是分层解耦。因为业务层是不可能去考虑持久化细节的。
ORM与SQL层还有个细节上的区别，就是O。ORM处理的是业务对象，SQL处理的是数据。你可以去了解一下，.NET中引入Typed Data Set的用意，就能了解到为什么我们需要更多的关注O。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cnapc
- (明月照大江)
- 等 级：
解耦对于大多数系统来说是必要的
同样对于IDE或语言也是一样,它们也有客户就是开发者,它们同样需要解耦,分层/封装不同的逻辑和实现
如果他们如同偶做出的软件,笨重而又繁琐,大概也不会有多少人使用了...
偶觉得啊,ORM处理的不能够是业务对象,只能是数据对象,如同Java中的实体Bean,这样也许就是你开始说的
NHibernate的轻便快捷?
偶只是将数据对象通过ORM和后台数据作映射(关系也好,存储也好),
而数据之间的存储关系是有穷的,完全可以通过某些表达式来表述.
而逻辑关系应该不会有什么样的东东能够完全涵盖,如果有那一定是AI了
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- acqy
- (sunnychen.org)
- 等 级：
个人认为，ORM的任务就是在业务层“不知道持久化机制是什么、如何工作”的情况下，维持业务对象的“持久化”状态。当业务对象需要持久化时，ORM完成持久化；当业务对象需要从持久化机制中重建时，ORM重建对象。
Hibernate这一词感觉也很有用意：（业务对象的）冬眠，明确说明了持久化这一状态。
当然，我还是坚持具体情况具体分析。不是所有的应用需要ORM。ORM至少会要付出性能代价，是否采用ORM应该要根据应用的规模以及其它的非业务性需求。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- michael_jiwei
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- isline
- (Aicken)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- microtry
- (编程就是照猫画虎)
- 等 级：
而功能界面确实各个独立的模块和权限管理;
并且,一个订单业务的来源和目标都有可能是不同的组织机构,
再则,不同的角色对数据的操作方式和输出方式是千差万别的,
比如,应用程序提供的搜索引擎输入"张三",你将要提供关于张三的所有类型的订单索引,然后由用户选择以后再进入精确处理模式,
那种基于CURD和数据驱动思想的方法将会使项目根本经不起需求的风吹草动,更不要说促进用户发展了好文，谢谢LZ
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bonhomme
- 等 级：
另外你说的从DataGrid直接提交对实体对象的更改，好像和ORM本身没有直接联系，而且在数据访问层理关照UI的实现，从一般的架构原则看，似乎欠妥。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- lingshixiao
- (★圣殿骑士)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dagecc01
- 等 级：
关系管理,你说的应该是数据库表格的关系吧.
在C#代码里,我专门定义了
表格标签TableAttribute,
视图标签ViewAttribute,
存储过程标签ProcessAttribute,
函数标签FunctionAttribute
主键标签PrimaryAttribute
外键标签ForeignAttribute
列标签ColumnAttribute
表与表间的关系,在早期的版本中,是通过ForeignAttribute来标注的.
现在是通过实体类的组合来实现的.
[ORMCombination( "productInfo.productInfoType InnerJoin productTypeInfo.productinfotypeID ")]//如果采用不含形参的ORMCombination,系统会自动根据表格的外键信息来关联.
public class TestReport
{
public productInfo;
public productTypeInfo;
.......
}
------------------
另外,我这套不仅仅只是ORM的功能,还包括数据访问,AOP,IoC,日志,异常,缓存,安全与授权,简单工作流等组件,如果说有个实体类的容器,那加强这个实体类容器的功能是一件有必要的事.这正好符合我们的目的:快速开发ERP,敏捷反应客户的需求.
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dagecc01
- 等 级：
6月后,组件库会发布一个版本,开发会暂停.
8月后,我们研发组会转入图形学,唉.头大.
希望在未结束之前把东西做的更好.希望能在大家身上多学点知识.
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bonhomme
- 等 级：
我的肤浅感觉：你的东西与其说是ORM（对象关系映射），不如说是ROM（关系对象映射），或者叫DOM（DB object mapping，数据库对象映射），也就是说你的是以数据库为出发点，力求在C#对象中“一对一”映射“各种”“物理的”“数据库实现”概念，例如你说的表、视图、存储过程、函数、主键、外键等，奥，对了，你还缺了触发器，是写帖子的时候忘记列出来了吧？
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- friky
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dagecc01
- 等 级：
我的肤浅感觉：你的东西与其说是ORM（对象关系映射），不如说是ROM（关系对象映射），或者叫DOM（DB object mapping，数据库对象映射），也就是说你的是以数据库为出发点，力求在C#对象中“一对一”映射“各种”“物理的”“数据库实现”概念，例如你说的表、视图、存储过程、函数、主键、外键等，奥，对了，你还缺了触发器，是写帖子的时候忘记列出来了吧？
=======================================
to bonhomme;
下面是来自: http://www.javaref.cn/topics/Hibernate/1458.html 的一段话:
-----------------------------------------------------------
2、什么是ORM？
ORM（Object-Relation
Mapping）是对象-关系映射，当下流行的开发语言都是面向对象的，如Java，C#。而当下流行的DB大多都是面向关系的，也就是关系数据库。这样在面向对象与面向关系之间需要一个桥梁，才能使二者协同无缝联合工作，ORM就是这个桥梁。映射关系如下：
[类] <=> [表]
[对象实例] <=> [表的行]
[属性] <=> [表的列]
那么这些映射关系是如何制定的呢？——只需要一个映射文件（XML）即可，在其中配置持久化类与DB表的映射关系后，ORM中间件在运行时参照此文件内容，对象持久化的DB中或把DB中数据加载到持久化类中。
Hibernate就是一个卓越的ORM中间件。
-----------------------------------------------------------
他说的很简明: 面向对象语言要与关系数据库之间有个桥梁.
只要做到了这点,就可以算是ORM.
ORM本来就是以数据库为出发点,为的就是要解决OO与关系数据库的映射.让程序员去少写SQL语句.
写在string 里的SQL语句,在编译的时候是无法发现错误的.更改了数据库的字段名称,就算现在的IDE有重构,但是你要重构字符串,那也是一个噩梦,他会把一些不需要重构的字符串也替换掉.
为什么要有函数和存储过程,这个是为了用户更加方便的调用.有很多老的系统,里面存在大量的存储过程和函数,新的系统要使用老的数据库,支持函数和存储过程,我认为是很有必要的.
为什么没有触发器,嘿嘿,我不喜欢这个东西,所以就没有.很多ORM还不支持存储过程和函数呢.
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dagecc01
- 等 级：
15、什么是ORM？常用的ORM架构有哪几种？
ORM是对象关系映射（object relation mapping) 。一种将关系型数据转化城面向对象数据进行处理的过程。就是为了不让在逻辑层看到大量的SQL语句。将关系型数据库中的数据（往往妨在表中）采用一种映射mapping，（通过XML文件的方式），转换成直接用面向对象的语言去操作，这样就可以避免使用SQL . 常用的ORM框架有：java中hibernate。.net中的nhibernate和grove 。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- dagecc01
- 等 级：
什么是ORM?
对象角色建模（ORM）提供了概念性的、易于理解的模型化数据的方法。ORM方法论基于三个核心原则：
· 简单。以最基本的形式建模数据。
· 传达性。数据库结构被任何人都能理解的语言文档化。
· 精确性。基于数据模型创建正确标准化了的结构。
典型地，建模者通过收集来自那些熟悉应用程序但不熟练的数据建模者的人的信息开发信息模型。建模者必须能够用非技术企业专家可以理解的术语在概念层次上与数据结构进行通讯。建模者也必须能以简单的单元分析信息，对样本数据进行处理。ORM专门被设计为改进这种联系。
规则表达式
ORM把应用程序世界表示为具有角色（关系中的部分）的一组对象（实体或值）。ORM有时也称为基于事实的建模，因为它把相关数据描述为基本事实。这些事实如果分割为再小的事实就会丢失信息。
简单事实的一些例子包括：
· 人有电话
· 人住在某个地方
· 人生于某个日期
· 人在某个日期被雇佣
这些事实相应的ORM模型如下：
图 1. 对象角色模型
图中的圆代表对象；矩形代表论断。在ORM中，象在逻辑中一样，一个论断只是带有对象洞的语句。箭头和点代表系统中的约束。
例如，在 "人有电话 "这个事实的诊断上的箭头可以翻译为：
有可能某个人有多于一个电话，并且至少有一个人有电话。
在 "人生于某个日期 "这个事实中，在论断上的箭头与连接对象与论断的点的结合表明：
每个人确切地出生于一个日期。
与 ER的比较
实体关系（ER）是另一种类型的数据库建模。ORM模型的简单性与ER相应部分的比较：
图 2. 实体关系
ORM以简单对象和论断的形式描述企业事实，而实体关系方法论以术语实体（拥有属性并参与关系）描述世界。在图1的ORM例子中，人，电话，地址和日期都表示为扮演有相互联系的角色的对象。在ER例子中，人是一个实体，它由属性：地址和电话进行描述。
例如，如果要把地址分解为街道，城市，州，ZIP码，那么必须把地址改变为具有相应属性的实体类型，结果会改变人与地址间的关系。尽管在上面的ORM模型中表示的约束也可以在ER中表示，但只要向模型中增加节点，或编写应用程序代码对模型进行补充，就可以表示其它约束。
ORM的优点
ORM提供的不只是描述不同对象间关系的一个简单而直接的方式。从示例中，可以看出ORM还提供了灵活性。使用ORM创建的模型比使用其它方法创建的模型更有能力适应系统的变化。另外，ORM允许非技术企业专家按样本数据谈论模型，因此他们可以使用真实世界的数据验证模型。因为ORM允许重用对象，数据模型能自动映射到正确标准化的数据库结构。
ORM模型的简单性简化了数据库查询过程。使用ORM查询工具，用户可以访问期望数据，而不必理解数据库的底层结构。
数据库生成和遍历引挚
象所有优秀的模型方法一样，ORM也不只是一个概念。它包含了不同的设计过程以帮助建模者映射概念的和逻辑的模型，或使用转换引挚在这些模型间转换。
ORM模型也能够自动地映射到大多数流行的关系型数据库所实现的数据库结构。检查前面的例子，ORM模型能自动生成ER图表或逻辑模型（可以翻译为SQL 代码，并适用于所选择的数据库）。
总结
利用非技术企业专家的知识对于确保应用程序满足企业需求是重要的。ORM，Visual Studio .NET的一个特性，是一个最初的、易于使用的概念性数据模型方法。通过使用不只是只有数据库专家才能理解的语言，ORM使那些充分理解了企业对应用程序需求的人能直接参与设计。
ORM还支持完全的遍历引挚，因此一旦定义了企业需求，它们就能迅速的转化为逻辑和物理数据库图表。使用ORM，组织可以提高应用程序开发的效率，确保企业需求能被正确交付。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- gameboy766
- (古巴)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- xiaotupansy
- (Pansy)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- gare1000
- (qq:270515011 弄个)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- coolbyefish
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- frank_lee_cn
- (Frank)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bonhomme
- 等 级：
dagecc的帖子内容翔实而丰富，但来源不一，里面很多概念和主张当然有道理。
但问题是dagecc展示的设计和代码和这些概念与主张之间有多少联系，我只好保留我的判断不作回答了，相信大家仁者见仁，智者见智。大家不妨仔细琢磨一下dagecc引用的“桥梁论”，一个值得考量的问题在于：一对一桥梁还是逻辑对物理的桥梁。
ORM的灵魂在于对关系的管理和映射，不是拿类去映射表关系，而是把类的关系映射为表关系。 这是许多人的主张，包括我本人。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- frank_lee_cn
- (Frank)
- 等 级：
是，你挺有见解的。
尤其是最后的那一句：ORM 的灵魂是把类的关系映射为表关系
我见到 dagecc 再跟他谈谈。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- frank_lee_cn
- (Frank)
- 等 级：
你提到的 一对一桥梁 还是 逻辑对物理桥梁，
不知道我有没有误解你的意思。
你说的是，dagecc 做的，是一对一的桥梁，即，一个表对象，有一个类对象来对应。
而你觉得，逻辑对物理的桥梁对应才是对的。
是这样子的意思吗﹖
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bonhomme
- 等 级：
再次感谢你对我的话题的兴趣。
关于我前帖中提到的“一对一 vs 逻辑对物理”这个问题：ORM应该使得程序员不但是用类来做数据库操作，而且要通过类来“思考”业务模型，或者换句话说，ORM要做的不是如何把数据库概念和行为映射为类和对象的概念和行为，而是把类和对象的概念和行为映射为数据库的概念和行为。这个话反正表达，实质含义有很大差别！
另外，我感觉 dagecc如果能举一个例子展示一下他们是如何实现我所展示的“厂家-客户-产品-订单”的例子，我认为更容易让大家理解他们的产品，以削除误解。最好，再加上一个“产品类别”(ProductCategory)的概念，要求是产品类别是树形的，允许任意明细的。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- frank_lee_cn
- (Frank)
- 等 级：
> 这个话反正表达，实质含义有很大差别！
是的，这个反正表达的部份，我理解。
> 通过类来“思考”业务模型
是的，这句话我同意。
> 另外，我感觉 dagecc 如果能举一个例子展示一下.....
我问过他，他当初贴帖回应的目的，就是为了能和你有些切磋、共同成长。
不过，因为他很少进来 CSDN，所以他留了 QQ 号希望能得到你的参与。
但很显然你比较喜欢在 CSDN 上谈，
所以你们对不上话。
没有关系，你当初贴帖的目的，我想
主要你想表达你对 ORM 的了解，分享给大家。
得到回应，我想你已经达到的目的。
dagecc 他的东西，是公司内产品，恐怕是不能再贴到这里来了。
而你的帖从一开始，就是以产品无关的角度来说明的，
我觉得这样子很好，
从观念上来理清ORM是什么，对我来说已经够了。
加上你提出了你对 dagecc ORM 的观点，
不管谁对谁错，
至少我知道你持的观点了。
dagecc 跟我谈了多次他的ORM产品，
我一直不太明白判断他的ORM好坏或对错的判断点是什么，
以至于一直没能给他好的建议。
你提你持的观点，让我一下子明白了许多。
我想dagecc提他观点的目的已经间接地达到了。
我在网上找到了一篇关于 ORM 的文章，
http://www.agiledata.org/essays/mappingObjects.html
原本看不太懂它的关键点，
有了你们这帖的讨论，
我一下子明白了这篇ORM的关键点。
因此，必须多谢你们的讨论，
我从中学习了不少。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- bonhomme
- 等 级：
我不敢说dagecc的观点不对，因为他没有方便能在这里充分暴露他的观点，但对他已经提出的若干细节，我还是坦率地提出了我自己的不同见解。我只是在研究一点ORM的概念，dagecc走的比我远，因为他已经做出了产品了。
我的QQ是459561863，希望和你们二位成为朋友，并请转告dagecc，也许我是他的老乡。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- eastsun_genius
- (大漠狂沙)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- zj_fanyu
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- linlinselina
- 等 级：
2年以上相关工作经验.良好的教育背景.
有朋友CV请推荐:Selina@mst.com.cn
msn:lin830413@hotmail.com
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- iloveppmm
- (mmlover)
- 等 级：
找了N（多的我都记不清了）多的资料，都没有能解决我的疑问。都是擦边球。
这个 正中要害。
有了清醒的认识，再去学个ORM框架，想必事半功倍了。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- eshopbar2008
- (eshopbar2008)
- 等 级：
本人在项目实践中，总结出用hastable来保存实体对象属性与表字段的对应关系。欢迎讨论一下。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- JYYCOM
- (横眉冷对)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- ireenter
- (明振居士)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- shawn_yang
- (shawn)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
这使我想起了我早前写过的第一个ORM。那里，我给自己的第一位的要求是：自动适应版本升级。就是在数据库中有一个“版本号”，在代码中也有一个“版本号”，程序的各个类型的.cctor（静态初始化）方法中会去比较这个版本号，并且它会自动升级数据表（包括建表，删除过去有而现在没有的字段、索引、外键、过程等等，增加过去没有而现在新增的一切设置）。既然你已经在代码中使用Attribute标记出来了，那么你的程序员就不应该手动到数据库管理系统中去创建和修改数据库结构，全都由.net程序代劳了。
这样做，bonhomme 的意思就明白了。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
不要忘记，反射只需要进行一次，就缓冲在static变量中了。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
这个想法也可以算有楼主的想法的萌芽。不过.net对这类任务有着比“使用XML管理”更为专业的框架方法，其实就是楼主的“Attribute+反射”技术，可以直接拿来开发更为高级的功能，而不是停在研究底层技术上浪费时间。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- tabris17
- (四不象)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sp1234
- (宇宙哲学并不如高强度的测试实践)
- 等 级：
2
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- flyingfz
- (戴眼镜的野人)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- sun1976
- (嫁给我,你就是我的一妾)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- makecodeeasy
- (makecodeeasy)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- abcn
- (小宝,上酸菜)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- hanjoe109
- (子人★雪怡----了空★博天)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cooolchen
- (新的，一切都是新的。)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- yqyqyoyo
- (事物缥缈)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- chxljtt
- (浮云何时飞)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cnapc
- (明月照大江)
- 等 级：
个人觉得保持一个干净简单的目标软件设计框架是应用ORM的前提,ORM的实现倒不是太复杂的事情
可以相互参考.net和Java的ORM实现,有助于理解ORM的构造是为什么
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- suinon
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- acqy
- (sunnychen.org)
- 等 级：
从分层角度考虑，领域层不应该考虑存储细节问题。在领域对象上设置“Table”、“PrimaryKey”等特性，事实上已经违背了这样的规律。
有兴趣的读者可以去比较一下Castle ActiveRecord以及NHibernate，虽然CA是建立在NHibernate之上，但意思完全不一样。
当然，也不是说NHibernate才是正道，如果项目规模不大，领域层对象关系不复杂的情况下，采用类似于Castle ActiveRecord这样的ORM或许更加轻便快捷。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cnapc
- (明月照大江)
- 等 级：
偶们没必要认为ORM就是DB的Administrator,该划分到DB层的实现,还是划分到DB层.
Table的结构/View/存储过程,本来就是DB和应用的接口
如果不使用ORM,现在的代码还不是一样要关联到数据库的细节?
如果偶们认为ORM是一个编程工具(的规范),是不是会好理解些?
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- acqy
- (sunnychen.org)
- 等 级：
ORM的引入正是为了在业务层（传统三层结构中的业务层）中屏蔽数据库（或者说是外部存储机制）的访问细节，使得业务层能够更加专注在解决业务问题上，而不是访问数据库上。相对较差的设计是，在业务层布满了繁杂的SQL或者存储过程的调用，此时当你的后台数据库有变更的时候，你将会被这一大堆SQL所困扰。在此，说相对较差的意思是，我们需要具体情况具体分析，加入系统本身就不大，那你引入ORM也没必要。如果系统对性能要求很高，那么还不如直接使用ADO。
从效果上来看，ORM确实是让我们少写许多代码。但ORM绝不仅仅是让我们少写些代码这样“肤浅”。这正如MVP模式一样，它使得应用系统的某个层能够更加独立（解耦）于其它层，这样才能使得应用系统更具备扩展性。ORM解决的是状态持久化问题，数据库是目前最为通用的数据保存机制，但对于对象状态的持久化，它不是唯一的机制。比如，对象完全可以在被序列化以后保存到XML文件中。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cnapc
- (明月照大江)
- 等 级：
不要将某些概念想的太复杂，它们的目的真的很简单呢？
ORM做解耦？代价就太大了。
数据库难道不包括XML数据库？
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cnapc
- (明月照大江)
- 等 级：
而是各人的表述概念可能有不一样,ORM的确是封装了数据后台
而它对于偶来说也的确是一个工具,不用自己封装不同的数据SQL代码,不用写烦人的某些很相像的代码...
事实上,偶自己做了个类似于Java中Persist概念的库,来处理这些问题
所以从俩个角度来说,全正确
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- acqy
- (sunnychen.org)
- 等 级：
我想说明的是，其实数据库概念很广泛，关系型数据库只不过是其中的一种。
你可以选择自己的SQL层而不使用任何ORM，完全取决于你自己。但是无论是你自己写的SQL层，还是ORM，都不得不承担同样一个责任，就是分层解耦。因为业务层是不可能去考虑持久化细节的。
ORM与SQL层还有个细节上的区别，就是O。ORM处理的是业务对象，SQL处理的是数据。你可以去了解一下，.NET中引入Typed Data Set的用意，就能了解到为什么我们需要更多的关注O。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- acqy
- (sunnychen.org)
- 等 级：
我想说明的是，其实数据库概念很广泛，关系型数据库只不过是其中的一种。
你可以选择自己的SQL层而不使用任何ORM，完全取决于你自己。但是无论是你自己写的SQL层，还是ORM，都不得不承担同样一个责任，就是分层解耦。因为业务层是不可能去考虑持久化细节的。
ORM与SQL层还有个细节上的区别，就是O。ORM处理的是业务对象，SQL处理的是数据。你可以去了解一下，.NET中引入Typed Data Set的用意，就能了解到为什么我们需要更多的关注O。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- cnapc
- (明月照大江)
- 等 级：
解耦对于大多数系统来说是必要的
同样对于IDE或语言也是一样,它们也有客户就是开发者,它们同样需要解耦,分层/封装不同的逻辑和实现
如果他们如同偶做出的软件,笨重而又繁琐,大概也不会有多少人使用了...
偶觉得啊,ORM处理的不能够是业务对象,只能是数据对象,如同Java中的实体Bean,这样也许就是你开始说的
NHibernate的轻便快捷?
偶只是将数据对象通过ORM和后台数据作映射(关系也好,存储也好),
而数据之间的存储关系是有穷的,完全可以通过某些表达式来表述.
而逻辑关系应该不会有什么样的东东能够完全涵盖,如果有那一定是AI了
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- acqy
- (sunnychen.org)
- 等 级：
个人认为，ORM的任务就是在业务层“不知道持久化机制是什么、如何工作”的情况下，维持业务对象的“持久化”状态。当业务对象需要持久化时，ORM完成持久化；当业务对象需要从持久化机制中重建时，ORM重建对象。
Hibernate这一词感觉也很有用意：（业务对象的）冬眠，明确说明了持久化这一状态。
当然，我还是坚持具体情况具体分析。不是所有的应用需要ORM。ORM至少会要付出性能代价，是否采用ORM应该要根据应用的规模以及其它的非业务性需求。
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- michael_jiwei
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- isline
- (Aicken)
- 等 级：
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
- microtry
- (编程就是照猫画虎)
- 等 级：
而功能界面确实各个独立的模块和权限管理;
并且,一个订单业务的来源和目标都有可能是不同的组织机构,
再则,不同的角色对数据的操作方式和输出方式是千差万别的,
比如,应用程序提供的搜索引擎输入"张三",你将要提供关于张三的所有类型的订单索引,然后由用户选择以后再进入精确处理模式,
那种基于CURD和数据驱动思想的方法将会使项目根本经不起需求的风吹草动,更不要说促进用户发展了http://topic.csdn.net/u/20070525/17/9ccaa2f5-82ad-458b-90b1-3f9768304d75.html
我老是怀疑我对象是什么原因
面向对象数据库、对象-关系数据库、XML三者之间有什么相同点和不同点
概念性商品
.NET概念清楚的高手请进来,问一些关于.NET概念性的问题
有关路由和映射的关系
函数与映射的关系与区别？
映射关系是一一对应的关系吗？
映射映射映射映射
陈小春有女友吗？有没有怀疑的对象？
怀疑自己是性病，专家请进来。
面向对象程序设计中对象、类、实例的关系
概念性物理题20分
初三数学概念性问题
概念性的问题
几个概念性问题
化学概念性问题
什么关系才叫对象(男女朋友)
个人简历示例
对象怎么搞呢?高手请进
wuizzard请进：如何找一个对象？
动态网页的对象问题,高手请进!@@
家庭关系高手请进!
我妈怀疑我和一个女孩关系有鬼
机器总死机，怀疑和硬盘有关系