分层架构里如果不用实体类该用什么传递数据
研究分层设计（目前还是三层）有一段时间，发现分层设计最大的一个问题，就是当数据库里的表要进行字段增加减少的时候，非常致命，改起来很头疼，我就不理解，按照我的想法，像淘宝这样的网站，难道他们的数据库里的表，可以设计出来后很长一段时间都不需要改的吗？
另外，分层设计主要靠实体类在各层之间传递数据，有人提出过说分层设计中实体类不是必须的，可以不要，如果不要它的话用什么传递数据呢？
最后，数据库在进行写入操作时，从设计的角度讲，能否应该写入NULL值，比如一个最简单的留言板，当用户留言的时候，管理员还没回复，管理员回复和管理员回复时间那里就是空的，实体类要传空值是一个比较麻烦的问题啊，该怎么解决这个？

------解决方案--------------------
1.数据表设计时会预留一些空字段，以便将来扩展，sql语句是写全的，这些字段启动时不需要再重写。
2.不要实体的话可以用dataset，但这不符合面向对象的思想。
3.很简单，把该字段设置成允许为空，不要插入数据就行了。
------解决方案--------------------
传值的方法有很多。。。不一定是实体类、、、、可以使 ado.net实体数据模型
Entity frameWork
这样你该数据库的时候只需要更新一下模型文件就行了。。。
至于你说的留言板问题。。。我不是很明白。。。管理员没有回复。。。（管理员回复表里没有这个数据）这个若没有这条数据就让文本框为空值就行了。。。。回复了就插入到表里去。。应该牵扯不到实体类传值的问题吧。。。。
------解决方案--------------------
客户留言和管理员回复是放在一个表里的？
客户只写入客户部分的。。。。管理员部分的就是空的了。。你吧管理员部分的 可以为空就行了。。。
实体类。。和为空不为空没有关系吧。。。而且只是一个字段是空的。。。
如果对象对空的话是不行的，
但是你只是一个字段。。。。
------解决方案--------------------
A.表的设计有一个原则，功能单一性，管理员和客户填写的内容即便是一对一的关系也要分成两个表，这样不会有冲突.
B.数据库已投入运营后，标准的做法是不会再对表进行字段的添加(也不会用预留字段的方式来解决这样的问题，这是底级做法),如果要添加也是再新建一个表(因为这个和字段值为Null的时,在业务上如何表示null值有关，还有历史数据也有关,并且是依赖于架构的设计),如果用DataSet这种表模式，则层与层之间的依赖最大了(逻辑层与数据层)，好的设计讲就合适的隔离(不是分离)及良好的接口定义,数据层的结构变了，不影响逻辑层，逻辑层的数据结构变了，不影响表示层,要做到这样要设计好隔离层(服务层)，这也是架构设计其中一个难点，不是一两句话能说清楚的，而且选择那种方式或技术也是关键(个人行为),用DataSet和class还是两种都不用，都要它们的好与坏一面，需要根据业务进行权衡
------解决方案--------------------
当你用面向对象来分析，一切就会非常的清晰。
一个对象代表的是一种业务模型，你何必去在意内部接口字段增加、减少。比如当我们处理一条作业流程的时候
1、人输入数据
2、计算处理数据
3、输出想要的业务对象数据
计算机处理数据这个就不是我们关系的问题，就好比你说的当字段增加、减少要如何设计数据层一样。数据层只是单纯的读数据而已。
对象与对象之间的传递是表达两个业务模型的边界、关系，从而得到自己所需要的业务对象模型，而不是因为对象中的某个字段。
比如
public class A
{
..........
}
public class B
{
........
}
//处理自己的业务对象
public class C
{
public T Print(A a,B b)
{
//处理对象间的关系
}
}
------解决方案--------------------
楼主可以参考一下在下的http://topic.csdn.net/u/20120425/18/8867f95b-117f-4fa8-8536-41162058704f.html?seed=1690017314&r=78371672#r_78371672，不依赖于数据库表的字段，可以自由的添加或删除某些字段，不会增加工作量。
------解决方案--------------------
三层之所谓为三层，是因为有了“业务逻辑层”。实体负责在表现层和业务逻辑层之间传送数据，例如“提交任务”命令中，提交的数据包括任务本身、任务的附件、表示任务是否应该自动驱动工作流的标记、表示任务是否是测试任务的标记，表示任务应该通过业务逻辑层自动给哪些群用户发提醒消息的集合列表。也就是说这个任务有5个实体参数。而实际上“任务实体”内容包括什么？它包括任务头信息、任务明细信息、任务的流转授权信息、任务的警报信息等等，也就是说这个实体在数据库中可能对应3个表、5个表，或者更多的表。但是在实体定义中也就是一个实体而已——因为最初的业务逻辑分析时期根本没有纠缠什么数据库表设计，数据库表是之后逐步设计和重构出来的。

实体是用来进行表现层和业务逻辑层之间通讯使用的。但是如果你看到一些“整天纠结在DAL层上，甚至硬要讨论是不是一个实体一定对应一个数据库表”这类概念时，这其实很烦。例如上面的业务逻辑层的实现代码，就可以直接动态产生一些sql语句，该去访问几个表就访问几个表，访问数据库是很灵活的，不需要“为了三层而三层”地搞什么PetShot式的所谓DAL层。

直接调用Linq Provider、ORM、面向对象数据库、NOSql、ADO.NET等等都是DAL的编写方法，不是只有僵化地为每一个实体对应出什么DAL类代码才叫做三层。实际上纠缠着这种DAL代码上，妨害了正确地灵活运用三层架构，妨害了你把精力放在业务逻辑层设计上。很多纠结于DAL层编码的人，其实都找借口忽视BLL层，而根本不会把精力放在BLL层设计上。