|
1
16
其他人可能会使用技术解答(例如查询语法、使用缓存、易用性或其他方式映射到现有数据库结构)——但是如果有一个已建立的ORM层,答案很可能是 “为什么要改变”? 多年来,我成功地将XPO应用于一个已有几百个用户的商业产品中。我发现它很快,很灵活,做的工作。我认为目前没有必要改变,因为我们的数据量并不是特别大,缺点(主要是缓存)是我们可以解决的。 如果我重新开始,我肯定会同时考虑NHibernate和ADO.NET实体框架。但实际上,一切都是好的;在技术问题之前,我很可能先看一下项目的商业情况。 例如,NHibernate是开源的——是否有一个可行的社区来支持这个工具并提供(如有必要)商业支持? XPO来自一个工具供应商,他们是否有可能在产品的生命周期内保持业务? ADO.NET实体框架来自微软,微软以经常改变数据库技术而臭名昭著,而拉里则用飞机燃料来填充他的战斗机——这也会消失吗? |
|
|
2
10
我发现与XPO合作非常令人沮丧。ORM的主要思想是抽象底层数据结构。但很快你就会注意到它们的默认字符串长度硬编码为60个字符,所以你最终会在每个字符串周围添加这些难看的字符串。太抽象了。。。 当建模更复杂的对象时,必须使用很多在对象模型中没有位置的语法,比如XPCollection。我想在类上存储一个包含字符串字典的类,但遗憾的是XPO无法自动将其存储到数据库中。 因此,虽然对于简单类型来说它可以正常工作,但是当您想要存储更复杂的东西时,它很快就会崩溃。再加上他们平庸的支持,真的还有很多需要改进的地方。 |
|
|
3
4
我已经使用它6-7个月了,对我来说,卖主是他们所有的UI组件都与XPO相对无缝地工作,而且他们的UI组件是一流的。 有些人可能会注意到,他们的论坛监控不力,几乎没有有用的流量——这是真的。但秘诀是填好票。他们对所有的支持票反应迅速,准确。 |
|
|
4
4
XPO总体上很容易使用。然而,当您计划使用遗留数据库或尝试将其引入brownfield应用程序时,可能会有点痛苦。我遇到的最痛苦的障碍是:
正如丹尼斯在评论中指出的,自从我最初写下这个答案以来,XPO有了很大的改进。特别是,以下事情不再是一个问题:
另外,下面的问题将不再是下一个XPO版本的问题,将在今年晚些时候发布:
总而言之,XPO有了很大的改进。大多数痛苦的障碍被消除了。使用遗留数据库时仍然可能遇到问题。但总体上XPO变得非常方便使用。 |
|
|
5
2
XPO ver 10.2现在支持StoredProcedures和sqlquerys。参见信息 here ... |
|
|
6
0
利弊比较什么?有很多选择,最受欢迎的是nHibernate,在块上有一个新的孩子“ADO.NET实体框架”。 不管怎样,根据你的情况和要求,有成百上千的答案。 |
|
|
7
0
我喜欢这样一个事实,你可以只创建类,xpo为你创建表和关系-所以你可以从一个空白的数据库开始。 我不喜欢的一个问题是,当我想删除一大堆东西时,它会遍历我的收藏,并对每一个进行删除。这需要很长时间,所以对于此类实例,我必须编写一些自定义sql(从blah所在的表中删除)。我不是XPO专家,但我就是这么发现的。 |
|
|
8
0
我第二个事实是,删除带有一些集合的复杂对象需要非常非常长的时间。到目前为止,文档或论坛还不能帮我解决这个问题。 除此之外,它的使用非常简单,让你走得很快。 也很难计算出你的内存使用情况,我的设计中有复杂的大对象,使用它们比我想象的要占用更多的内存。 |
|
|
9
0
这是开始编写域对象所需的全部操作(请尝试在其他系统中执行相同的操作):
|
|
|
user384884 · Dapper返回零guid 2 年前 |
|
|
qanqanqan · 如何在Django ORM中通过最大值获取对象 2 年前 |
|
|
Kirill · Django RawSQL注释字段 2 年前 |
|
|
nepko · Django将字符串过滤为整数? 2 年前 |
|
|
Emirhan Ay · 用实体框架建立两个实体之间的关系 2 年前 |