17,740
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
bucher 2004-03-18
- 打赏
- 举报
呵呵，有没有人考虑过O/R mapping的安全问题，如何得到一个经过审核对象列表而不是全部的列表。简单的ID-ID的TableRelation不能解决问题，你如何知道对象的类型呢？用户组的权限交集也比较麻烦，花了我很长的时间。
这个问题看似简单，差点搞死我的Framework。
这个问题看似简单，差点搞死我的Framework。
lkal4587 2004-03-15
- 打赏
- 举报
up
CKL 2004-03-15
- 打赏
- 举报
尽管方便了，但就目前的硬件水平来说，o/r mapping 和 sql 在速度上的差别还是很明显的
xinxiangpeng 2004-03-14
- 打赏
- 举报
学习ing
marshine 2004-03-12
- 打赏
- 举报
to progame:
对你的东西很有兴趣，也同意你的观点，可以给我发邮件（我的网站上有）。
对你的东西很有兴趣，也同意你的观点，可以给我发邮件（我的网站上有）。
progame 2004-03-11
- 打赏
- 举报
to: barton131420(嘉士伯)、 marshine(marshine)
我给你们二位都发消息，因为首先我们的目标都是一样，就是实现.Net下的orm，并且最重要的一点，就是开源，所以我希望大家可以共同交流讨论，防止不必要的错误和重复开发，并把一些创造性的想法融合在一起，我目前在开发的是一个提供平台无关SQL到本地SQL转换的broker层，并且希望以后这个broker可以对orm提供crud和ooq支持。
我给你们二位都发消息，因为首先我们的目标都是一样，就是实现.Net下的orm，并且最重要的一点，就是开源，所以我希望大家可以共同交流讨论，防止不必要的错误和重复开发，并把一些创造性的想法融合在一起，我目前在开发的是一个提供平台无关SQL到本地SQL转换的broker层，并且希望以后这个broker可以对orm提供crud和ooq支持。
hasty 2004-03-11
- 打赏
- 举报
to barton131420(嘉士伯)：非常感谢!
我们作的软件是由条件定制着一个过程，现在做的是在每一个部署的地点，根据具体情况，我们的技术支持会定制这些条件，以后客户有什么需求改变的话还需要技术支持去支持，如果没有变化就省事多了。这是我们具体的业务需求。我们现在开始试着作了，是针对我们具体的业务的。
如果有什么问题在麻烦你吧，有了新的收获也会告诉你，更希望早一点看到你的产品。
我们作的软件是由条件定制着一个过程，现在做的是在每一个部署的地点，根据具体情况，我们的技术支持会定制这些条件，以后客户有什么需求改变的话还需要技术支持去支持，如果没有变化就省事多了。这是我们具体的业务需求。我们现在开始试着作了，是针对我们具体的业务的。
如果有什么问题在麻烦你吧，有了新的收获也会告诉你，更希望早一点看到你的产品。
i386 2004-03-11
- 打赏
- 举报
晕,头大,我从未听说过 O-R MAPPING 以及相关理论,今天进来受教育了
不过我做的项目里基本上都是把数据及其操作包装成类，进入业务逻辑。
典型的一个类，包括
1.ThisRow属性。thisRow 就是类型化的datarow，可以直接抄用自动生成的xsd了
2.idRow属性。这没啥好说的把
3.三个构造函数,一个默认，一个按id构造，一个创建新datarow
4.Modify(..)方法和Delete()方法，分别对该对象进行相应操作。
5.idObject 静态属性。该类在项目object库中的 id。
6.GetDataView(..) 静态方法，按参数获取整个数据表的dv。
7.其他特殊的方法和属性。
这些方法和属性都是修改和访问dataset实现。而dataset则靠adapter，adapter靠sp去和数据库最终交互。
在业务逻辑和最上层，全部实现调用相应的对象操作。
不出现一句 sql。虽说性能差一点，但实现了编程本身和数据库操作的分离。
不知道这算不算最原始的自发的O-R萌芽，呵呵
这是俺自己慢慢总结出来的
俺水平低，列位不要笑话阿
不过我做的项目里基本上都是把数据及其操作包装成类，进入业务逻辑。
典型的一个类，包括
1.ThisRow属性。thisRow 就是类型化的datarow，可以直接抄用自动生成的xsd了
2.idRow属性。这没啥好说的把
3.三个构造函数,一个默认，一个按id构造，一个创建新datarow
4.Modify(..)方法和Delete()方法，分别对该对象进行相应操作。
5.idObject 静态属性。该类在项目object库中的 id。
6.GetDataView(..) 静态方法，按参数获取整个数据表的dv。
7.其他特殊的方法和属性。
这些方法和属性都是修改和访问dataset实现。而dataset则靠adapter，adapter靠sp去和数据库最终交互。
在业务逻辑和最上层，全部实现调用相应的对象操作。
不出现一句 sql。虽说性能差一点，但实现了编程本身和数据库操作的分离。
不知道这算不算最原始的自发的O-R萌芽，呵呵
这是俺自己慢慢总结出来的
俺水平低，列位不要笑话阿
barton131420 2004-03-10
- 打赏
- 举报
>>在部署的时候才会知道一些表示层的具体要求，才能最终确定界面的样式
我认为大多数情况下，是因为需求调研不够所致。当然不排除客户会有一些递进需求，关键看这些需求是否在合理的能够接受的范围内，否则应由客户承担这部分责任。
ECO是Enterprise Core Objects,Borland的产品,在C#Builder1和Delphi8的架构版上都带。它与裁剪过的UML建模工具Together一起工作。是早期Java上的一个O-R Mapping框架Bold在.NET上的实现。最近几期的《程序员》杂志在连载陈省的介绍文章。它可以自动生成业务层和持久层代码。
我认为大多数情况下，是因为需求调研不够所致。当然不排除客户会有一些递进需求，关键看这些需求是否在合理的能够接受的范围内，否则应由客户承担这部分责任。
ECO是Enterprise Core Objects,Borland的产品,在C#Builder1和Delphi8的架构版上都带。它与裁剪过的UML建模工具Together一起工作。是早期Java上的一个O-R Mapping框架Bold在.NET上的实现。最近几期的《程序员》杂志在连载陈省的介绍文章。它可以自动生成业务层和持久层代码。
hasty 2004-03-10
- 打赏
- 举报
to barton131420(嘉士伯) ：谢谢你的回答！
我们的具体需求确实有一点特殊，我们用其他方法实现了，就是研究怎么转化成面向对想的思想，在者就是看怎么来提高开发速度；因为现在的实现方法总是在需求变化一点的情况下，修改很地方。最难解决的问题是我们在部署的时候才会知道一些表示层的具体要求，才能最终确定界面的样式，不过界面的表示只是在一定范围内变化的。
我想在问一个问题，你说的eco，我好像没有接触过相关的资料，你能给简单介绍一下或者介绍一下相关的资料行吗？
我们的具体需求确实有一点特殊，我们用其他方法实现了，就是研究怎么转化成面向对想的思想，在者就是看怎么来提高开发速度；因为现在的实现方法总是在需求变化一点的情况下，修改很地方。最难解决的问题是我们在部署的时候才会知道一些表示层的具体要求，才能最终确定界面的样式，不过界面的表示只是在一定范围内变化的。
我想在问一个问题，你说的eco，我好像没有接触过相关的资料，你能给简单介绍一下或者介绍一下相关的资料行吗？
barton131420 2004-03-10
- 打赏
- 举报
我的思路是这样的：从ER建模成果(别提UML，这家伙整得我很惨)，一部分直接生成ORP类型文档，由Yukon自己处理持久化问题；另一部分生成与Yukon类型完全兼容的业务对象代码，通过业务层对对象缓存、并发和事务的处理来实现复杂业务逻辑。
barton131420 2004-03-10
- 打赏
- 举报
我决定将我的这个框架设计成一个开源的项目，我将它命名为Kanas.NET(Kanas是新疆北部一个怡人的风景区，蒙古语的意思是“美丽而神秘”)，将集众家之所长，但现在还不是可以发布的时候。
我考虑了我的Kanas.NET与未来Yukon的ORP互相支持的问题。据我所知目前还没有这样的产品。这对.NET下的项目开发将是极大的推动力。
我考虑了我的Kanas.NET与未来Yukon的ORP互相支持的问题。据我所知目前还没有这样的产品。这对.NET下的项目开发将是极大的推动力。
barton131420 2004-03-10
- 打赏
- 举报
hasty:很高兴与你探讨有关对象关系映射方面的问题。我对XPO还有你说的DeKlarit都有过研究。XPO的确不错，设计简单。但用的是字段/属性，这显然不能与ECO用的值表相提并论。DeKlarit是从另外一个角度来实现的，一方面每一个实体都是一个Component，实现类似EJB的模型，另一方面提供了一个可视化的设计界面，简化了程序员的认识和操作。特别是对计算属性的处理得极好。
在用户那里添加对象属性？我不能理解。一旦改动对象结构，意味着你必须在数据库表、BO/DO层、业务规则层、界面四处作相应的修改。依照.NET强大的反射功能，除业务规则层外同步过程是可以自动化的，但显然会失去某些个性化的属性。
如果是我，我一定会将每一层都用一个单独的Assembly来封装，泛化所有的共性，将特异性的部分抽出来加强可配置性即可。虽然.NET的EMIT可以在运行时生成IL代码，但毕竟没有获得设计期支持，更无法调试。所以在非编译环境下做到修改对象结构我认为并不可取。
在用户那里添加对象属性？我不能理解。一旦改动对象结构，意味着你必须在数据库表、BO/DO层、业务规则层、界面四处作相应的修改。依照.NET强大的反射功能，除业务规则层外同步过程是可以自动化的，但显然会失去某些个性化的属性。
如果是我，我一定会将每一层都用一个单独的Assembly来封装，泛化所有的共性，将特异性的部分抽出来加强可配置性即可。虽然.NET的EMIT可以在运行时生成IL代码，但毕竟没有获得设计期支持，更无法调试。所以在非编译环境下做到修改对象结构我认为并不可取。
hasty 2004-03-09
- 打赏
- 举报
barton131420(嘉士伯):看了你的留言有很多收获，我这有xpo的源代码（花钱买的），对他的实现机制也研究了一下，和你说的差不多，它也是用反射来实现的；但是如果我们想做一个支持在用户那里动态添加对象属性的数据访问层，能否给点建议？也就是能够支持在发布之后动态的添加对象的属性信息。我对着方面还很迷茫，请指点？
我们用其他方法实现了，就是不知道继承到数据访问层中怎么来实现。
你的程序可以拿出来大家参考一下吗？我在网上down了一个Deklarit，他的功能和你说得差不多。
我们用其他方法实现了，就是不知道继承到数据访问层中怎么来实现。
你的程序可以拿出来大家参考一下吗？我在网上down了一个Deklarit，他的功能和你说得差不多。
Jaguar1982 2004-03-09
- 打赏
- 举报
to ahead_lin(Try my best!):
我觉得SP FUNCTION等当然有存在的必要
所以真正的持久层
应该是对数据库的表，存储过程，视图的扫描而生成的XML
我觉得SP FUNCTION等当然有存在的必要
所以真正的持久层
应该是对数据库的表，存储过程，视图的扫描而生成的XML
marshine 2004-03-09
- 打赏
- 举报
想不到研究o/r mapping的还很多，我前年也作了个o/r mapping框架（PDO），目前正准备开发一个全新的版本。PDO目前是开发源码的(www.marshine.com)，欢迎各位交流。
ahead_lin 2004-03-08
- 打赏
- 举报
感觉ORM处理一些简单的操作如CRUD等还可以.但处理负责的逻辑,还需要SP,Function来实现.但这样就破坏了ORM的本意:使程序员脱离数据库的思考模式.
还有,如果ORM实现的好,那SP,Function等还有生存的必要吗?
郁闷ing
个人看法,欢迎指正.
还有,如果ORM实现的好,那SP,Function等还有生存的必要吗?
郁闷ing
个人看法,欢迎指正.
01101230 2004-03-08
- 打赏
- 举报
楼上：“业务实体对应了数据库中的字段信息......”
这只是大多数情况，很多时候业务实体并不需要对数据库字段做一一映射的。
这只是大多数情况，很多时候业务实体并不需要对数据库字段做一一映射的。
Jaguar1982 2004-03-07
- 打赏
- 举报
因为业务实体对应了数据库中的字段信息,
所以我是想在.net中调用存储过程的时候(它包括字段名,字段信息,字段大小等),能直接利用XML来读取存储过程所对应的业务实体。
这样的好处在于：一旦数据库变动不大的情况下，调用存储过程的语句就无需改变。
我是这么理解o/r:它是对数据库的映射，一旦改变数据库，代码可以尽可能的少或者根本无须改变
我不知道我的理解对否？请你们指教
所以我是想在.net中调用存储过程的时候(它包括字段名,字段信息,字段大小等),能直接利用XML来读取存储过程所对应的业务实体。
这样的好处在于：一旦数据库变动不大的情况下，调用存储过程的语句就无需改变。
我是这么理解o/r:它是对数据库的映射，一旦改变数据库，代码可以尽可能的少或者根本无须改变
我不知道我的理解对否？请你们指教
timiil 2004-02-28
- 打赏
- 举报
XPO的pj不难，小弟弄了一个，强人可否一试？
加载更多回复（51）
