三层架构中的实体层问题。
三层架构的实体层怎样才能反射数据库字段自动生成成员字段并编译成类呢？（好像代码生成器一样的功能）

案例：每一次都是先建好数据库，然后在写实体层，假如现在业务变多了，增加了几个数据库字段，那实体层的成员就要改了，并且数据层的插入语句都也需要改了，

实体层怎让才能反射数据库字段自动生成成员字段并编译成类呢？这样的话，后台的拓展性就变强了，不考虑资源问题，也不考虑两个表（结构表和内容表）来实现。

就想在原来的数据库中增加字段，并自动生成实体层类。
------解决方案--------------------

引用:

三层架构的实体层怎样才能反射数据库字段自动生成成员字段并编译成类呢？（好像代码生成器一样的功能）

案例：每一次都是先建好数据库，然后在写实体层，假如现在业务变多了，增加了几个数据库字段，那实体层的成员就要改了，并且数据层的插入语句都也需要改了，

实体层怎让才能反射数据库字段自动生成成员字段并编译成类呢？这样的话，后台的拓展性就变强了，不考虑资源问题，也不考虑两个表（结构表和内容表）来实现。

就想在原来的数据库中增加字段，并自动生成实体层类。

如果你增加了数据库字段，你的实体需要修改？那么你就被 EF 之类的 DAL 给误导了。

实体是用于表现层跟业务逻辑层之间交换（经常进行“序列化、反序列化”）数据用的。比如说某个前段需求的接口功能，它只需要返回某个只有5个属性的实体，而你的数据库表中对应的表（假设这个实体仅仅对应一个数据库表，而不是多个）却有15个字段，那么你的实体也仍然是仅需要取这5个属性而已，用不着修改为15个属性。

如果你和说来说去就只有数据库表概念，那么你完全没有必要搞什么“三层”编程。直接从你的表现层，使用ADO.NET，访问关系数据库，这岂不是更加直接和简洁一点？！因为此时你没有进行分层开发的需求。

而假设需要分层开发，不要反而被八股文章给害了，不要反而变繁琐了。