讨论下.net下怎么做才算是面向对象思想开发数据库 越看越晕，越想越觉得走火入魔，在数据库开发中，用面向对象的思想来做太复杂了，究竟什么做才算是面向对象思想开发数据库，或者跟数据库开发中可以不需要用面向对象的思想来实现？大家谈谈嘛！！ 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 去研究下ORM比如现在的LINQ TO SQL ，就是面向对象的操作数据库，当然LINQ的功能不仅仅如此， 先说说你的思想吧；大致可以这样：1、把数据库中的数据抽象为一个或几个类，2、最好选用桥接模式或Adapter模式来读取/保存/更新数据3、数据库是数据读取后放到你前面抽象的类中，再从类的实例显示到UI控件；看楼下如何做！ 用VS2008的新特性 LINQ 他操作数据的思想就是面向对象的思想。。我用过。。呵呵 看你的需求情况不适合情况:1: 小项目或小程序。2: 无中间层(物理的中间层,中间层可以运行于单独服务器的) 其实就是负载一个服务器（同上运行数据库或中间层）就可以搞定的。3: 数据量超大且需做大量统计报表。4: 对用户响应率要求极高。5：主力开发人员喜欢写SQL且比较老成且不想改变。6: 道听途说且无探索精神、无主见、无信心的(温总理说: 信心比黄金重要)我们采用ORM技术构建了3层的技术框架，目前应用于多个中型项目，数据量可以支撑每天50W记录，再高没有测。我们以前也曾经怀疑过，主要是担心性能问题，现在一切都没问题！其实看你怎么灵活去用，那是牛人帮我们准备的技术套件，我们能灵活利用就能提高效率！ 面向对象不关心数据库，因为目前主流数据库都不是面向对象的...所以才会有ORM这种东西出来解决这种矛盾... 1、把数据库中的数据抽象为一个或几个类， 2、最好选用桥接模式或Adapter模式来读取/保存/更新数据 3、数据库是数据读取后放到你前面抽象的类中，再从类的实例显示到UI控件； 面向对象不关心数据库，因为目前主流数据库都不是面向对象的...所以才会有ORM这种东西出来解决这种矛盾... 用面向对象建立数据库模型，也可使用ORM：将数据库表映射到类、将记录映射到对象、将字段映射到对象的属性。参考 ORM非常符合面向对象思想，但是如果要操作较复杂的数据库表多表连接什么的就在性能上逊色了，项目也有很多就直接把数据表字段对应成对象属性，就是所谓的实体对象来操作，也很符合面向对象思想 Castle这个开源的activerecord是这个思想，可以去看看 其实只要你把软件分成真正意义上的三层,orm层让在dal层中,上面用接口调用,数据量不是很大时,用orm开发很快,而orm可以不关心数据库.如果出现性能问题,你可以通过接口来用sql语句或sql存储过程来重建一个dal层,实事上,一般系统最复杂的部分是逻辑层和界面,访问数据的接口相对固定,重构是很方便的.其实一般系统出现性能问题最大的原因往往是负载比较大的地方,这一部分,你可以直接用sql方式,而这不会影响你orm其他方面的.用90%事让orm做,舒服安全,10%是性能高的部分让sql做,不安全,但快.用orm如果是查询结果比较多,用分页,一次取几十条子记录,也不会出现性能问题.如果是导出数据,数据量很大,你可以另用sql做,这样性能也不是问题.如果是汇总或多个表的查询,最好是用sql视图,用orm映射视图,这样性能也不是问题.如果是事务驱动的,只是对数据库的锁和共享比较关心,用orm最方便解决这些不是问题的问题.这样就不出出现什么性能问题了.担心orm性能是一种伪科学,因为orm不是用来查询极大数据量的,实事上查询极大数据时都是分页,你看百度和淘宝那个不分页,分页的20条记录怕什么,orm是用来加快开发速度,降低开发难度的.当数据访问量大时,用orm的可以提高数据库的访问效率,因为大多数程序在数据量大时做得不好的地方是解决数据库死锁,共享,和输出的缓存问题,还有数据库的连接池的问题.而这些orm都是默认给你优化的. 我觉得单就对后台数据库这块而言，现在的数据库都是关系型数据库，无所谓有没有面向对象这种概念面向对象是中间层业务逻辑上的观点，所以两者之间才有ORM之类的东西出来做转换，或者自己把面向对象的业务逻辑用SQL语句等分解然后和数据库挂钩除非SQL 2010 不是建表了，而是建的都是对象模型，然后一条记录打开就是一个可编辑的对象sql语句是直接对这些内置对象操作的 最近在看 Thinking in UML, 里面认为 将 关系数据库中的二维表 映射到类，是不面向对象的！ OODB没有成功商业化,才有ORM这个四不像。 看你的需求情况 不适合情况: 1: 小项目或小程序。 2: 无中间层(物理的中间层,中间层可以运行于单独服务器的) 其实就是负载一个服务器（同上运行数据库或中间层）就可以搞定的。 3: 数据量超大且需做大量统计报表。 4: 对用户响应率要求极高。 5：主力开发人员喜欢写SQL且比较老成且不想改变。 6: 道听途说且无探索精神、无主见、无信心的(温总理说: 信心比黄金重要) 我们采用ORM技术构建了3层的技术框架，目前应用于多个中型项目，数据量可以支撑每天50W记录，再高没有测。 我们以前也曾经怀疑过，主要是担心性能问题，现在一切都没问题！ 其实看你怎么灵活去用，那是牛人帮我们准备的技术套件，我们能灵活利用就能提高效率！ 字符串处理 求学习方法请给我点帮助 请教一个通讯问题（高手请进） datagridview 批量 更新 數據 怎样能随机输出Web服务器控件!!! 关于IP换代理的问题 如何对另外一个wpf窗口的控件进行操作 能否在vs.net2003下用C＃语言操作yahoo邮箱来发电子邮件？能提供类似的C＃例子更好，谢谢！ 能否用c#开发activeX控件否？ C#编写数据库应用程序方便吗？ 在C#中,如何实现十进制个二进制之间的转化 winform中的datagrid怎么没有colomns属性
大致可以这样：
1、把数据库中的数据抽象为一个或几个类，
2、最好选用桥接模式或Adapter模式来读取/保存/更新数据
3、数据库是数据读取后放到你前面抽象的类中，再从类的实例显示到UI控件；
看楼下如何做！
他操作数据的思想就是面向对象的思想。。我用过。。呵呵
不适合情况:
1: 小项目或小程序。
2: 无中间层(物理的中间层,中间层可以运行于单独服务器的)
其实就是负载一个服务器（同上运行数据库或中间层）就可以搞定的。
3: 数据量超大且需做大量统计报表。
4: 对用户响应率要求极高。
5：主力开发人员喜欢写SQL且比较老成且不想改变。
6: 道听途说且无探索精神、无主见、无信心的(温总理说: 信心比黄金重要)我们采用ORM技术构建了3层的技术框架，目前应用于多个中型项目，数据量可以支撑每天50W记录，再高没有测。
我们以前也曾经怀疑过，主要是担心性能问题，现在一切都没问题！
其实看你怎么灵活去用，那是牛人帮我们准备的技术套件，我们能灵活利用就能提高效率！
2、最好选用桥接模式或Adapter模式来读取/保存/更新数据
3、数据库是数据读取后放到你前面抽象的类中，再从类的实例显示到UI控件；
参考
其实只要你把软件分成真正意义上的三层,orm层让在dal层中,上面用接口调用,数据量不是很大时,用orm开发很快,而orm可以不关心数据库.
如果出现性能问题,你可以通过接口来用sql语句或sql存储过程来重建一个dal层,实事上,一般系统最复杂的部分是逻辑层和界面,访问数据的接口相对固定,重构是很方便的.其实一般系统出现性能问题最大的原因往往是负载比较大的地方,这一部分,你可以直接用sql方式,而这不会影响你orm其他方面的.用90%事让orm做,舒服安全,10%是性能高的部分让sql做,不安全,但快.
用orm如果是查询结果比较多,用分页,一次取几十条子记录,也不会出现性能问题.如果是导出数据,数据量很大,你可以另用sql做,这样性能也不是问题.如果是汇总或多个表的查询,最好是用sql视图,用orm映射视图,这样性能也不是问题.如果是事务驱动的,只是对数据库的锁和共享比较关心,用orm最方便解决这些不是问题的问题.这样就不出出现什么性能问题了.担心orm性能是一种伪科学,因为orm不是用来查询极大数据量的,实事上查询极大数据时都是分页,你看百度和淘宝那个不分页,分页的20条记录怕什么,orm是用来加快开发速度,降低开发难度的.当数据访问量大时,用orm的可以提高数据库的访问效率,因为大多数程序在数据量大时做得不好的地方是解决数据库死锁,共享,和输出的缓存问题,还有数据库的连接池的问题.而这些orm都是默认给你优化的.
面向对象是中间层业务逻辑上的观点，所以两者之间才有ORM之类的东西出来做转换，或者自己把面向对象的业务逻辑用SQL语句等分解然后和数据库挂钩
除非SQL 2010 不是建表了，而是建的都是对象模型，然后一条记录打开就是一个可编辑的对象
sql语句是直接对这些内置对象操作的
不适合情况:
1: 小项目或小程序。
2: 无中间层(物理的中间层,中间层可以运行于单独服务器的)
其实就是负载一个服务器（同上运行数据库或中间层）就可以搞定的。
3: 数据量超大且需做大量统计报表。
4: 对用户响应率要求极高。
5：主力开发人员喜欢写SQL且比较老成且不想改变。
6: 道听途说且无探索精神、无主见、无信心的(温总理说: 信心比黄金重要) 我们采用ORM技术构建了3层的技术框架，目前应用于多个中型项目，数据量可以支撑每天50W记录，再高没有测。
我们以前也曾经怀疑过，主要是担心性能问题，现在一切都没问题！
其实看你怎么灵活去用，那是牛人帮我们准备的技术套件，我们能灵活利用就能提高效率！