多个对象 跟 一个对象多个属性有什么区别

多个对象 和 一个对象多个属性有什么区别
新手,好像对这个不理解,求大神指教
------解决思路----------------------
List是集合
Model是类
你可以认为这是一组对象的集合
------解决思路----------------------

引用:

在DAL层使用insert时,我有多个参数需要插入
这里应该是1个对象的多个属性吧
List<MODEL>又是什么呢

        public List<MODEL.T> G()
        {
            DAL.S _obj = new DAL.S();
            DataTable _dt = _obj.GT().Tables[0];
            List<MODEL.T> _list = new List<MODEL.T>();
            foreach (DataRow dr in _dt.Rows)
            {
                MODEL.T _t = new MODEL.T();
                _t.M = Convert.ToInt32(dr["M"]);
                switch (Convert.ToInt32(dr["M"]))
                {
...
                }
                _t.SID = Convert.ToInt32(dr["SID"]);
                _list.Add(_t);
            }
            return _list;
        }

其实把面向对象稍微稍微深入理解就很简单了，不论是list还是map或是hashmap都是类，就好比交通工具，然后呢你实例化交通工具得说明是装什么的吧，所以list好比火车<>好比车厢，里面就是你要装的一类东西，可以是木材，煤炭...木材，煤炭都是类，那么就会有属性，大小，重量等等属性。这里你把每根木材的属性赋值，再一根根存到所要存的列车箱list中就好了。延伸一下，一列火车不止一列车厢，可以再实例化list<can>去存车厢，当然每节车厢放什么你说了算
------解决思路----------------------
类就是一个类别
对象就是属于这个类的一个具体的东西
属性就是用来描述这个对象的
list 就是对相同类的对象的集合
娶个例子：
人类，这是一个类  我说道人类的时候你无法想象出某一个特定的人，但是人类都有手，脚，可以站立，我说到人类的时候你心里已经有了一些人类所特有的特点，这就是属性。
对象，人类中的特定一个人，比如你，就是一个对象
集合List : 一个大房子，里边很多跟你一样的人，即有相同的属性，属于同一个类：人类   这就是集合。
------解决思路----------------------

引用:

Quote: 引用:

脱离开对象，属性也可以是对象，比如人由四肢、身体，头组成，这时候人是一个对象，四肢什么的就是人的属性，如果脱离开了人，四肢什么的也可以单独作为一个对象，比如四肢就有指甲、手指（脚趾）什么的组成

您好,那我想问下,比如我在DAL层使用insert时,我有多个参数需要插入,那么我可以创建一个对象,包含多个属性进行赋值插入,
也可以使用list<MODEL>这种形式创建多个对象的字段,对相应的对象赋值是么

DAL就是数据驱动功能，目的是稍微通用一些的数据库操作。例如极其通用的ADO.NET就是一种DAL（通常人们还会设计一套SQLHelper架构层来提高ADO.NET的封装性）。而如果你自己要写上100个增删改查的“很繁琐的类型和方法”来单独做数据库层访问（就像费力的PetShop风格似地），也可以算是DAL。但是最基本的原则是，DAL的设计与业务逻辑设计无关，它只是方便于数据的通用的增删改查操作就行了。

而通常，如果专门针对你自己的.net自定义类型业务实体对象进行DAL操作，这叫做ORM。它的目的就是封装出一套高级的、更省力的面向对象实体的DAL操作api来。例如EF就是一种ORM。同时ORM自然也是一种DAL。

如果说你觉得EF这类的架构都不够好，你可以自己设计一套更好的架构，针对List<T>之类的而专门进行数据库增删改查和事务操作。但是总之这也是DAL范畴的。跟业务逻辑层设计无关。

于是，结论是，这是越来越接近于底层的、为了编程方便而封装的一些底层方法。在编程中当然希望将来可以“仅写一句话”就能重复实现一些功能，而不是“粘贴+复制”方式来贴多条语句。你这里所担心的“一个对象还是多个对象的区别”的问题，只是一个比较底层的技术问题，够不上程序设计层次的问题的高度。在较底层的技术实现问题上，不要被概念所捆绑。