110,566
社区成员
发帖
与我相关
我的任务
分享ORM框架选型问题
我现在的需求是，使用C/S模式进行开发，我想把ORM这块放到客户端执行，但是客户端不能够通过Connection连接数据库，而需要通过一个数据服务连接数据库。
请问，有没有一种ORM框架能够满足我的需求呢？
请问，有没有一种ORM框架能够满足我的需求呢？
...全文
请发表友善的回复…
发表回复
不老神仙 2011-10-19
- 打赏
- 举报
学习 关注
连风 2011-06-30
- 打赏
- 举报
非常感谢大家的帮忙，结贴了！
连风 2011-06-27
- 打赏
- 举报
回复：JonnySun
关于Winform开发框架桥接功能
http://www.csframework.com/archive/5/arc-5-20110615-1601.htm
桥接功能是建立客户端与服务端的通道(Chennel)
http://www.csframework.com/cs-framework-3.0.htm
后台数据更新流程(DataTable,DataSet)
http://www.csframework.com/archive/4/arc-4-20110401-1274.htm
ORM+SqlClient组件数据更新模型
http://www.csframework.com/archive/4/arc-4-20110401-1275.htm
希望对你有所帮助。
谢谢！
关于Winform开发框架桥接功能
http://www.csframework.com/archive/5/arc-5-20110615-1601.htm
桥接功能是建立客户端与服务端的通道(Chennel)
http://www.csframework.com/cs-framework-3.0.htm
后台数据更新流程(DataTable,DataSet)
http://www.csframework.com/archive/4/arc-4-20110401-1274.htm
ORM+SqlClient组件数据更新模型
http://www.csframework.com/archive/4/arc-4-20110401-1275.htm
希望对你有所帮助。
谢谢！
连风 2011-06-27
- 打赏
- 举报
回复：JonnySun
》》》
说几句：
ORM是指对象关系映射模型，很多人喜欢称为实体类，这是一个完全独立的且底层的东西，几乎没有业务方法，当然没有CRUD功能。
通常的作法是：ORM实例化为对象后用于存储缓存的数据，比如一个字典数据，一张业务单据。提交数据是通过BLL->DAL->DB这个流程的，NHibernate或其它持久层架构只是负责将ORM的实例对象的数据通过SqlOleDb或其它DataProvider存储到数据库服务器的，NHibernate的思路是通过ORM的XML定义生动生成SQL, 然后枚举ILIst 对象生成一条条对应的SQL语句, 整个更新流程由一个事务完成。
我现在的问题是，没办法使用SqlOleDb，所以无法完成存储！
那我有没有可能自己做DataProvider呢？就是通过网络，自己实现呢？
》》》
说几句：
ORM是指对象关系映射模型，很多人喜欢称为实体类，这是一个完全独立的且底层的东西，几乎没有业务方法，当然没有CRUD功能。
通常的作法是：ORM实例化为对象后用于存储缓存的数据，比如一个字典数据，一张业务单据。提交数据是通过BLL->DAL->DB这个流程的，NHibernate或其它持久层架构只是负责将ORM的实例对象的数据通过SqlOleDb或其它DataProvider存储到数据库服务器的，NHibernate的思路是通过ORM的XML定义生动生成SQL, 然后枚举ILIst 对象生成一条条对应的SQL语句, 整个更新流程由一个事务完成。
我现在的问题是，没办法使用SqlOleDb，所以无法完成存储！
那我有没有可能自己做DataProvider呢？就是通过网络，自己实现呢？
连风 2011-06-27
- 打赏
- 举报
[Quote=引用 22 楼 moneysoft 的回复:]
引用 21 楼 dqdan 的回复:
或者是在说接口颗粒度的问题吗？
这个想法还有点靠谱,楼主的问题貌似和orm没关系,
如果这些服务你们不能重构,
那么你们可以弄一个隔离层,你管他多少个接口,抽象出不超过20个新的服务类型,
客户端的代码可以大大减少,
这就是基本的面向对象设计:统一描述和分层
[/Quote]
非常感谢你的回复。
那么假设我现在已经将业务逻辑归类了，那么如果这些服务的实现，我想放到客户端执行，那么有没有成熟的orm框架可以使用呢？
引用 21 楼 dqdan 的回复:
或者是在说接口颗粒度的问题吗？
这个想法还有点靠谱,楼主的问题貌似和orm没关系,
如果这些服务你们不能重构,
那么你们可以弄一个隔离层,你管他多少个接口,抽象出不超过20个新的服务类型,
客户端的代码可以大大减少,
这就是基本的面向对象设计:统一描述和分层
[/Quote]
非常感谢你的回复。
那么假设我现在已经将业务逻辑归类了，那么如果这些服务的实现，我想放到客户端执行，那么有没有成熟的orm框架可以使用呢？
flyerwing 2011-06-27
- 打赏
- 举报
[Quote=引用 17 楼 dqdan 的回复:]
引用 15 楼 flyerwing 的回复:
肯定需要配置了.
一配置就好了,用过JSPSSH那几个框架的就很熟悉.
我的问题是，我需要在客户端运行ORM，但是，我不能保证客户端能够直接连接到数据库服务器，所以我不能使用配置数据库连接字符串的方式！
[/Quote]
是内外网网闸交换数据???那好象不能使用ORM.
引用 15 楼 flyerwing 的回复:
肯定需要配置了.
一配置就好了,用过JSPSSH那几个框架的就很熟悉.
我的问题是，我需要在客户端运行ORM，但是，我不能保证客户端能够直接连接到数据库服务器，所以我不能使用配置数据库连接字符串的方式！
[/Quote]
是内外网网闸交换数据???那好象不能使用ORM.
JonnySun 2011-06-27
- 打赏
- 举报
可能是我说的不太明白，我希望使用一种成熟的ORM框架，通常ORM框架都提供了基本业务逻辑功能，例如：通用的增删改查，事物等等，这样的话，ORM框架不就和Connection有关系了吗？
》》》
说几句：
ORM是指对象关系映射模型，很多人喜欢称为实体类，这是一个完全独立的且底层的东西，几乎没有业务方法，当然没有CRUD功能。
通常的作法是：ORM实例化为对象后用于存储缓存的数据，比如一个字典数据，一张业务单据。提交数据是通过BLL->DAL->DB这个流程的，NHibernate或其它持久层架构只是负责将ORM的实例对象的数据通过SqlOleDb或其它DataProvider存储到数据库服务器的，NHibernate的思路是通过ORM的XML定义生动生成SQL, 然后枚举ILIst 对象生成一条条对应的SQL语句, 整个更新流程由一个事务完成。
你的问题，根本原因是没有处理好分层，如果BLL, DAL是分离的，或者是分模块的，那么，不管改装为WebService或者 .Net Remoting, 或者Tcp/Ip, UDP 都不是问题， 你只需要在BLL与DAL之间增加一个中间层。
关于中间层，这里有份资料参考：
关于Winform开发框架桥接功能
http://www.csframework.com/archive/5/arc-5-20110615-1601.htm
桥接功能是建立客户端与服务端的通道(Chennel)
http://www.csframework.com/cs-framework-3.0.htm
----------------------------------------------------------------------------------------
》》》16楼：
你是想不去预先对服务进行业务分析，然后推卸给前端开发人员在“开发”时各自去搞数据库？这种软件作坊开发方法做不了你所说的100多个服务那样的系统的。
>>>>你的回答脱离群众了，他需要人提供思路去解决问题而不是训斥。
－－－－－－－－－－－－－－－－－－－
这个问题不是简单的ORM与CRUD, 架构级别了。
这里有几篇小文章去参考下：
后台数据更新流程(DataTable,DataSet)
http://www.csframework.com/archive/4/arc-4-20110401-1274.htm
ORM+SqlClient组件数据更新模型
http://www.csframework.com/archive/4/arc-4-20110401-1275.htm
希望对你有所帮助。
》》》
说几句：
ORM是指对象关系映射模型，很多人喜欢称为实体类，这是一个完全独立的且底层的东西，几乎没有业务方法，当然没有CRUD功能。
通常的作法是：ORM实例化为对象后用于存储缓存的数据，比如一个字典数据，一张业务单据。提交数据是通过BLL->DAL->DB这个流程的，NHibernate或其它持久层架构只是负责将ORM的实例对象的数据通过SqlOleDb或其它DataProvider存储到数据库服务器的，NHibernate的思路是通过ORM的XML定义生动生成SQL, 然后枚举ILIst 对象生成一条条对应的SQL语句, 整个更新流程由一个事务完成。
你的问题，根本原因是没有处理好分层，如果BLL, DAL是分离的，或者是分模块的，那么，不管改装为WebService或者 .Net Remoting, 或者Tcp/Ip, UDP 都不是问题， 你只需要在BLL与DAL之间增加一个中间层。
关于中间层，这里有份资料参考：
关于Winform开发框架桥接功能
http://www.csframework.com/archive/5/arc-5-20110615-1601.htm
桥接功能是建立客户端与服务端的通道(Chennel)
http://www.csframework.com/cs-framework-3.0.htm
----------------------------------------------------------------------------------------
》》》16楼：
你是想不去预先对服务进行业务分析，然后推卸给前端开发人员在“开发”时各自去搞数据库？这种软件作坊开发方法做不了你所说的100多个服务那样的系统的。
>>>>你的回答脱离群众了，他需要人提供思路去解决问题而不是训斥。
－－－－－－－－－－－－－－－－－－－
这个问题不是简单的ORM与CRUD, 架构级别了。
这里有几篇小文章去参考下：
后台数据更新流程(DataTable,DataSet)
http://www.csframework.com/archive/4/arc-4-20110401-1274.htm
ORM+SqlClient组件数据更新模型
http://www.csframework.com/archive/4/arc-4-20110401-1275.htm
希望对你有所帮助。
--缪军-- 2011-06-27
- 打赏
- 举报
[Quote=引用 21 楼 dqdan 的回复:]
或者是在说接口颗粒度的问题吗？
[/Quote]
这个想法还有点靠谱,楼主的问题貌似和orm没关系,
如果这些服务你们不能重构,
那么你们可以弄一个隔离层,你管他多少个接口,抽象出不超过20个新的服务类型,
客户端的代码可以大大减少,
这就是基本的面向对象设计:统一描述和分层
或者是在说接口颗粒度的问题吗？
[/Quote]
这个想法还有点靠谱,楼主的问题貌似和orm没关系,
如果这些服务你们不能重构,
那么你们可以弄一个隔离层,你管他多少个接口,抽象出不超过20个新的服务类型,
客户端的代码可以大大减少,
这就是基本的面向对象设计:统一描述和分层
连风 2011-06-27
- 打赏
- 举报
或者是在说接口颗粒度的问题吗？
连风 2011-06-27
- 打赏
- 举报
[Quote=引用 19 楼 sp1234 的回复:]
业务服务是根本。在动手开发之前，该不该做这个系统、用户要不要你的系统，你对业务服务的分析是否到位是个关键。看起来你没有耐心去设计规划系统，这是个问题。
[/Quote]
你的意思是说，我提到的那些100多个业务逻辑接口有问题吗？或许是这样做有问题吗？请指教！
业务服务是根本。在动手开发之前，该不该做这个系统、用户要不要你的系统，你对业务服务的分析是否到位是个关键。看起来你没有耐心去设计规划系统，这是个问题。
[/Quote]
你的意思是说，我提到的那些100多个业务逻辑接口有问题吗？或许是这样做有问题吗？请指教！
以专业开发人员为伍 2011-06-27
- 打赏
- 举报
业务服务是根本。在动手开发之前，该不该做这个系统、用户要不要你的系统，你对业务服务的分析是否到位是个关键。看起来你没有耐心去设计规划系统，这是个问题。
连风 2011-06-27
- 打赏
- 举报
[Quote=引用 16 楼 sp1234 的回复:]
你是想不去预先对服务进行业务分析，然后推卸给前端开发人员在“开发”时各自去搞数据库？这种软件作坊开发方法做不了你所说的100多个服务那样的系统的。
[/Quote]
汗，这么上纲上线的！我没有表达过此类意思吧！
我的想法是，我现在已经有了100多个业务逻辑接口，但是这些接口如果以服务的方式发布，那么服务就太多了，或者说，服务中的方法就太多了，所以我想把业务逻辑接口的实现放在客户端中（系统为C/S模型，客户端无法直接连接到数据库）。
但是这样做的话，我还没有找到一个合适的ORM框架可以使用。
你是想不去预先对服务进行业务分析，然后推卸给前端开发人员在“开发”时各自去搞数据库？这种软件作坊开发方法做不了你所说的100多个服务那样的系统的。
[/Quote]
汗，这么上纲上线的！我没有表达过此类意思吧！
我的想法是，我现在已经有了100多个业务逻辑接口，但是这些接口如果以服务的方式发布，那么服务就太多了，或者说，服务中的方法就太多了，所以我想把业务逻辑接口的实现放在客户端中（系统为C/S模型，客户端无法直接连接到数据库）。
但是这样做的话，我还没有找到一个合适的ORM框架可以使用。
连风 2011-06-27
- 打赏
- 举报
[Quote=引用 15 楼 flyerwing 的回复:]
肯定需要配置了.
一配置就好了,用过JSPSSH那几个框架的就很熟悉.
[/Quote]
我的问题是，我需要在客户端运行ORM，但是，我不能保证客户端能够直接连接到数据库服务器，所以我不能使用配置数据库连接字符串的方式！
肯定需要配置了.
一配置就好了,用过JSPSSH那几个框架的就很熟悉.
[/Quote]
我的问题是，我需要在客户端运行ORM，但是，我不能保证客户端能够直接连接到数据库服务器，所以我不能使用配置数据库连接字符串的方式！
以专业开发人员为伍 2011-06-27
- 打赏
- 举报
你是想不去预先对服务进行业务分析，然后推卸给前端开发人员在“开发”时各自去搞数据库？这种软件作坊开发方法做不了你所说的100多个服务那样的系统的。
flyerwing 2011-06-27
- 打赏
- 举报
肯定需要配置了.
一配置就好了,用过JSPSSH那几个框架的就很熟悉.
一配置就好了,用过JSPSSH那几个框架的就很熟悉.
连风 2011-06-27
- 打赏
- 举报
[Quote=引用 13 楼 flyerwing 的回复:]
hibernate,
entity frame,
ibatis,
.........
[/Quote]
我看了看，好像都需要配置数据库连接字符串啊！
hibernate,
entity frame,
ibatis,
.........
[/Quote]
我看了看，好像都需要配置数据库连接字符串啊！
flyerwing 2011-06-27
- 打赏
- 举报
hibernate,
entity frame,
ibatis,
.........
entity frame,
ibatis,
.........
连风 2011-06-27
- 打赏
- 举报
PS：这儿不讨论什么是ORM。。。
连风 2011-06-27
- 打赏
- 举报
[Quote=引用 10 楼 flyerwing 的回复:]
引用 1 楼 caozhy 的回复:
没有。
ORM 和 Connection 无关。
事实上你应该封装成 Web Service，你可以在服务器上用 ORM。也可以不用。
总之和客户端无关，ORM也没有封装连接的功能。
是地.楼猪概念先搞清
[/Quote]
可能是我说的不太明白，我希望使用一种成熟的ORM框架，通常ORM框架都提供了基本业务逻辑功能，例如：通用的增删改查，事物等等，这样的话，ORM框架不就和Connection有关系了吗？
引用 1 楼 caozhy 的回复:
没有。
ORM 和 Connection 无关。
事实上你应该封装成 Web Service，你可以在服务器上用 ORM。也可以不用。
总之和客户端无关，ORM也没有封装连接的功能。
是地.楼猪概念先搞清
[/Quote]
可能是我说的不太明白，我希望使用一种成熟的ORM框架，通常ORM框架都提供了基本业务逻辑功能，例如：通用的增删改查，事物等等，这样的话，ORM框架不就和Connection有关系了吗？
flyerwing 2011-06-27
- 打赏
- 举报
[Quote=引用 1 楼 caozhy 的回复:]
没有。
ORM 和 Connection 无关。
事实上你应该封装成 Web Service，你可以在服务器上用 ORM。也可以不用。
总之和客户端无关，ORM也没有封装连接的功能。
[/Quote]
是地.楼猪概念先搞清
没有。
ORM 和 Connection 无关。
事实上你应该封装成 Web Service，你可以在服务器上用 ORM。也可以不用。
总之和客户端无关，ORM也没有封装连接的功能。
[/Quote]
是地.楼猪概念先搞清
加载更多回复（18）
