在数据访问层中,有必要将所有方法的输入输出参数都规定为类实例对象吗?(ORM思想)

Question

因为有ORM的出现,所以在使用ORM组件的时候,在数据访问层中的输入输出参数几乎都是实列对象(或其数组),
但是在没有ORM组件的时候,有必要按照ORM的思想,构造类实体,在操作的时候输入输入都以类的实列为最小单位吗?比如查询一个学生(student类)信息,本来传入一个ID就可以查到,那么有必要将传入的参数改为student类型吗?比如构造一个student a=new student();   然后赋值a.id=1;
然后将这个a作为参数传入方法查询这个学生的信息,有必要这么做吗?

Answer 1

ORM好处到底在哪里?是不是把对数据库记录的更新延迟(先将该实列对象更新),然后一次性根据该对象更新数据库对应记录?
另外,这样其实影响速度的啊,

Answer 2

纠正下你的错误思想。ORM是工具，不是思想。OO（面向对象）才是思想。如果你的程序使用面向表结构的设计方式，以增删改查为主，业务逻辑简单，那么完全不用ORM，使用DataBind 设计就足够了。

Answer 3

这说明你对ORM的工作原理不理解。对于数据库，我们如何确定两处存储的记录是一条还是内容相同的两条。我们是通过主键(pk)实现的。因为pk是这样一种字段，同一张表中，不同的记录pk不同。
在面向对象的系统中，比如C#，我们如何知道两个对象是否相等？
比如：
Person p1 = new Person() { Name = "Zhangsan", ID = 1, Age = 17 };
Person p2 = new Person() { Name = "Zhangsan", ID = 1, Age = 17 };
Console.WriteLine(p1 == p2); // return false
很明显，这两个对象不同。
那么ORM框架做什么呢？它会映射PK，并且重写 Equals() 和 GetHashCode() 方法。
在一个ORM系统中，如果 PK 被正确映射，那么 p1 和 p2 是相等的。如ORM的目标，它将数据库和业务对象分离开来，业务中我们根本不关心 id 是不是 pk，所以避免传递 id 而是传递对象，让 ORM 框架去处理。
如果我们业务规则修改，比如将 e-mail 作为 pk 了（很多网站都是用 email 作为账户的），很明显，ORM 框架因为隔绝了数据库和业务关系，从而不需要修改代码，就可以转换过来，这就是ORM的价值。

Answer 4

这么说来ORM框架的好处就在于开发代码的时候方便,以及很好的实现了面向对象的思想,那么我在没有ORM的框架下,有必要按照ORM的效果来构建数据访问层吗?就是自己创建实体类,然后在DAL的各方法中传递的都是实体对象,有必要吗?

Answer 5

orm是这样的思想,先加载,后操作.

Answer 6

纯技术层面的分析不等于脱离实际需求的分析。ORM并没有解决把垃圾代码转换为优质代码的能力，也不能让程序变得“更加面向对象”。

Answer 7

ORM并不能简化开发。它可以相对来说简化你说的那种将对象手工映射到数据库，以及手工创建实体对象的情况。注意是相对的。打一个比方：自动变速箱可以简化汽车驾驶，但是汽车驾驶本身要比骑车复杂得多。所以如果你想找一种比骑车简单的方法，不应该考虑给自行车加上变速箱。

Answer 8

 
每次看到caozhy的回答 都能学到些东西~~