自定义实体（强类型）将会贯穿整个业务层 不是最好的 --- 我的面试经历

我昨天去一家深圳软件公司面试，非常郁闷，请各位同行指点迷津； 

我向一位项目经理展示了一套借鉴websharp开源架构和smartpersistencelayer架构的接口，建立了一套架构，其中一个重要的思想：自定义实体（强类型）将会贯穿整个业务层，显示层； 

这位项目经理与副总告诉我，这种理念可能不是更好的，自定义实体满天飞；他们采用的架构是：无需为每个对应数据库数据表建立一对一的实体，而是一个通用的接口，入口一个参数（可能是指定数据库的一个表）自动生成sql语句，实现显示层数据在数据库的增删改。 
我是否可以认为他们采用的是弱类型的数据传递与处理;   

我的疑问是   ：自定义实体（强类型）将会贯穿整个业务层   与   弱类型随时埋伏在业务层的各个角落 
我的郁闷是：他们认为我的这种自定义实体（强类型）将会贯穿整个业务层是不好的，过时的 

请同行给个说法   ，谢谢大家 
--------------------编程问答-------------------- 我个人认为确实不好，若后台数据库结构一变化，那还不得在你项目文件里到处Find-Replace啊，勿见笑！
--------------------编程问答-------------------- 无需为每个对应数据库数据表建立一对一的实体，而是一个通用的接口，入口一个参数（可能是指定数据库的一个表）自动生成sql语句，实现显示层数据在数据库的增删改。

以上是原始的（老掉牙的套路）～～

楼主说的方法是强行套用的～～～

可以说，这两种方法，半金八两～～ --------------------编程问答-------------------- @_@ --------------------编程问答-------------------- 我还是认为强类型的自定义实体比较容易接受些
毕竟数据库表结构经常在变化啊 --------------------编程问答-------------------- 每个数据库对应一个实体类(我是这么做的，新手)，看看高手的建议吧。 --------------------编程问答-------------------- re: 我个人认为确实不好，若后台数据库结构一变化，那还不得在你项目文件里到处Find-Replace啊，勿见笑！ 

我的进一步思考：
自定义强类型实体：
1. 我们不可以回避的是关系型的数据库，不是面向对象的。数据表更改，一定会引起业务层的更改，这是肯定。关键是否便于修改，容易修改吗，修改的是否彻底。studion强大的调试工具只有针对傻瓜的自定义强类型才有非常确切的识别，Find-replace;

弱类型通用实体接口：
1. 数据库结构变化了，业务层对通用实体引用的代吗不需要变化吗 ? 更加的是，可能还找不到在何处？改了一处，不知道其它模块是否会出问题，这样的程序结构健壮吗?


再次请教高手的建议 ！ --------------------编程问答-------------------- 当客户说我招标的项目很大，你会嫌项目大吗 ？ 不会

问题来了 ：你一定会准备好，关系型数据库数据表一定会很多；

关注这么多数据表，是肯定了。现在我们有了基本对应数据表自定义强类型实体后，只要关注自定义强类型实体，这何来业务设计工作量进一步加大，我实在不明 。 --------------------编程问答-------------------- 当客户说我招标的项目很大，你会嫌项目大吗   ？   不会 

问题来了   ：你一定会准备好，关系型数据库数据表一定会很多； 

关注这么多数据表，是肯定了。现在我们有了基本对应数据表自定义强类型实体后，只要关注自定义强类型实体，这何来业务设计工作量进一步加大，

如此多的数据库表，怎样的DAO层可使业务层设计使工作量减少 ，又健壮  。 --------------------编程问答-------------------- 关注 --------------------编程问答-------------------- 老陈，原来你在这里。
别灰心，继续努力。另外，我建议你，不要提自定义的实体类，我想，应该是自定义的对象，并且假设这些对象都是聪明的，智能的，它们会为自己的行为负责，并且提供了外界访问他们的最直观的方法。

补充：.NET技术 ,  ASP.NET