设计上的问题，大家来指点我下吧

[mooncat2000]

最近在 考虑很多设计方面的问题,觉得头疼

通常 Model Entity 应该 对应数据库的表，然后 越靠近用户 数据在内存中的保存方式越业务化（就是倾向于显示和使用）
如果是三层，则 BLL操作DAL，处理Model的CRUD，包上事务，并组合结果给表示层。
这过程中会组合2个或者更多的实体Model数据 成新的类
新的类叫什么VO也好，叫什么DTO也好，总感觉规模一大，各种表示层的需求会造成不同表和字段组合的自定义类型满天飞。
管理起来一塌糊涂。使用匿名类吧，又不能在函数间传递，还要装成Object。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
最近看了DDD,也一头雾水，我可以在设计的时候不考虑持久方式，可是，我终究要持久化，对象和表之间的阻抗还是存在的。
很少有人谈到我DDD设计了以后，怎么理清领域对象的持久化怎么做。
还有一点就是，做Web项目，感觉业务层对象的状态没什么意义，因为业务层通常被页面创建，对象的生命周期最长也就一个
page，还要想尽办法在Url里将一些东西传来传去。
然后，现在的很多新东西，IQueryable<T>,由于类型的延迟决定，无法序列化，无法在Session中保存。
很多查询条件，现在还都是以aaa=bbb的方式成对保存，类型很弱。

业务类对象现在也就一个函数或者一个Page的命，除了connectionString 我都不知道里面可以放些什么成员。
似乎就是一个函数集了。如果是这样，很多函数还分不清属于哪个领域根呢，我取名字都各应，
索性业务层就做个函数库算了，都static起来，是不是这样更好呢？
如果是这样，还不如直接写aspx.cs里，这样访问控件，Session都方便，也不过就一个函数库。

感觉要OO设计，则O的状态管理很重要，但是Web项目里，状态被每次提交都拆烂了，
我可怜的用Session、Cookie和GetURL Parameter 维护状态，太惨了......

想点办法　救救我

[zpisgod]

设计为功能服务，只要功能实现了 客户才不管你是用什么设计方式
如果功能都能很好的实现，都写在aspx.cs我也觉得挺好啊

所谓设计，为的是更好的团队合作，后期维护和扩展，具体采用什么还是要看你的业务，你的团队

[hch126163]

所谓设计，为的是更好的团队合作，后期维护和扩展，具体采用什么还是要看你的业务，你的团队！

索性业务层就做个函数库算了，都static起来，是不是这样更好呢？
所有静态，怎么又这个想法呢？你做web,每个访问服务器都会有一个线程来处理请求，都静态了，就只有一个实例！你怎么对应不同的请求呢？
还有静态是，应用程序开始就一直存在于内存，知道应用程序 结束！
这样不是很占用内存吗？

要是能这样，asp.net page 为什么每次请求都要经历生命周期，处理完请求后腰执行销毁呢

如果是这样，还不如直接写aspx.cs里，这样访问控件，Session都方便，也不过就一个函数库。

都写aspx.cs 里，你的一下代码怎么重用呢？

[以专业开发人员为伍]

[Quote=引用楼主 mooncat2000 的回复:]
新的类叫什么VO也好，叫什么DTO也好，总感觉规模一大，各种表示层的需求会造成不同表和字段组合的自定义类型满天飞。
[/Quote]

这就说明你没有参与过什么好的公司的项目。比如移动公司开发十几个api，就能给各种sp带来每年几十亿的市场。

[以专业开发人员为伍]

你纠缠于一些技术，比如把状态归咎于page的生命周期的局限，或者把需求归咎于空洞的数据库表字段，哪有什么产品概念，哪里能够很好地运用设计？我看不出来！

[以专业开发人员为伍]

设计跟编程语言有关系吗？跟asp.net有关系吗？

没有关系，别纠缠这些。先给出你到底设计了什么，别纠缠这些编程。

[threenewbee]

设计的问题需要很深的理论功底，从你的描述来看，你还需要很多学习。

[mooncat2000]

谢谢大家关注，忙了几天，没来看帖子

现在我的问题主要是，
1.项目中，往往不同的业务需求造成了各处不同的数据组织形式（如 A.a, A.b, B.c, C.e 组成一个新类）。
多层的结构造成了层间数据很难管理，各个业务逻辑都有自己的自定义数据类型
ClassA ClassB ClassC .... 满天飞。
这样一来各种签名版本的函数也非常混乱。其中还夹杂着到底到哪一步Select出多少字段，性能的纠结。
也想过将类型弱化提交 类似 DataSet 或者 Hashtable 或者 Array 这种
不过这样得以无法编译时报错和装拆箱性能来作为代价。
2.业务层类互相调用，功能的重用会导致以后对一个功能的修改会对未知个数的业务有影响。
（到现在都不是很清楚应该如何组织业务层，是不是用专门的IFacadeXXX接口定义出面对表示层的方法？
而不被这个接口定义的函数则可以被别的业务层调用?)
功能的重用导致了我的业务层会有层次结构,如果一个函数被其他5个业务使用，那我修改这个函数的时候
要知道哪几个业务使用了这个函数，我的这次修改会对他们造成影响么？
如果不是这样使用，那势必有些重复的功能，会重复写。
写到最后就是，每个相关业务一个业务类，一堆函数。
3. 业务类只能作为Page的成员，生命周期 也就一个函数,最多一次PostBack。
业务类就保持不了什么状态。
一些新玩意 IQueryable，表达式树 等 设计得是不错，但由于类型的晚确定，不好序列化
无法往Session里存（用外部stateservice必须要可序列化）

我最近在做电子商务的项目。
大家在项目里都是如何解决以上这些问题的呢？

[mooniscrazy]

其实，你想怎么做就怎么做。这类问题没有标准答案。能用最少的成本解决问题就行了。
真正的问题在于，如何去说服其他人，如何在不伤害他人感情的基础上让大家统一意见。

[wolftop]

用对象数据库可以弱化状态管理。 如db4o

http://www.db4o.com/china/

[ycproc]

[Quote=引用 3 楼 sp1234 的回复:]
引用楼主 mooncat2000 的回复:
新的类叫什么VO也好，叫什么DTO也好，总感觉规模一大，各种表示层的需求会造成不同表和字段组合的自定义类型满天飞。


这就说明你没有参与过什么好的公司的项目。比如移动公司开发十几个api，就能给各种sp带来每年几十亿的市场。
[/Quote]

很想做这样的项目 修内功 等机会

[silentcross]

我觉得你的出发点有问题，设计是从需求出发到业务模型到系统模型的一个可推导的过程
你抛开业务直接讨论什么IQueryable，这根本就没法说，你应该先了解统一过程，用这种思路来考虑问题，
而不是在复杂的细节中顾此失彼