1、所有对数据库的操作都放在存储过种里。
2、能在客户端实现的不要写在cs里面。
3、要用用户自定义控件。
4、最重要的一个就是关于基类的写法。
我现在不是很白的地方就是基类如何去写？尽量提高可重性，还有如何去考虑分层？表示层、数据库连接层和业务层,这我听说过，但是不知如何去实现。希望有这一方面经验的高手给一些指点和教导，拜谢！拜谢！
20 个解决方案
#1
这四条与架构好像都没有关系。
#2
表示层就是你的 aspx, html, css, js
业务层就是处理业务逻辑关系, 比如折扣算法, 验证规则, 还有就是把数据层提供的数据转换成表示层直接可用或可绑的规格
数据层就是访问数据库.
以上是我对分层的肤浅理解. 楼主装装VS2003里的Duwamish7看看吧
业务层就是处理业务逻辑关系, 比如折扣算法, 验证规则, 还有就是把数据层提供的数据转换成表示层直接可用或可绑的规格
数据层就是访问数据库.
以上是我对分层的肤浅理解. 楼主装装VS2003里的Duwamish7看看吧
#3
比如说你的第三条，如果所有的它们都有这样的接口就是专业的：
public interface ImyUI
{
IdomainObject obj{set};
event EventHandler onObjChanged;
}
其中，IdomainObject 是所有业务类型都具有的接口。
这个就应该算初步比较专业的UI层了。
把所有有关UI的函数、方法，全都组织在一个dll里，这是方法库的结构化思路，是很笨拙地甚至错误地理解“分层”这个概念的结果，根本不是面向对象的分层。
public interface ImyUI
{
IdomainObject obj{set};
event EventHandler onObjChanged;
}
其中，IdomainObject 是所有业务类型都具有的接口。
这个就应该算初步比较专业的UI层了。
把所有有关UI的函数、方法，全都组织在一个dll里，这是方法库的结构化思路，是很笨拙地甚至错误地理解“分层”这个概念的结果，根本不是面向对象的分层。
#4
再进一步解释一下上面的，比如说你的一个负责显示数据编辑的控件，它根据IdomainObject类型的参数产生界面元素，就像 vs 开发环境的属性编辑器一样根据对象自动产生每一个属性的编辑条，那么你这个控件就是成功的。
再大的系统，常用的控件也不过几个、十几个，剩下的就是业务逻辑设计。
再大的系统，常用的控件也不过几个、十几个，剩下的就是业务逻辑设计。
#5
上面所说的“常用的控件”是指构造 业务对象UI表现层 的控件，不是指那些底层的textbox等砖头瓦块。
其实很多人言必“分层”，但是并不知道如何分层才不芜杂。
其实很多人言必“分层”，但是并不知道如何分层才不芜杂。
#6
本来写了一大堆，结果CSDN告诉我：
请不要发表可能给我们带来伤害的言论，谢谢配合
还把我所有的文字都给弄丢了……
郁闷……
算了，简而言之。
任何一种架构和设计，都是为了更好的开发效率和适应今后的需求，有其适用场景，与设计模式一样，不要为了模式而模式，更不要为了架构而架构……
请不要发表可能给我们带来伤害的言论，谢谢配合
还把我所有的文字都给弄丢了……
郁闷……
算了，简而言之。
任何一种架构和设计，都是为了更好的开发效率和适应今后的需求，有其适用场景，与设计模式一样，不要为了模式而模式，更不要为了架构而架构……
#7
我说“IdomainObject 是所有业务类型都具有的接口”，如果你不仔细看这个“所有”二字，就会错误理解我的本来意思。
对框架的学习，一知半解滥竽充数没有用。
对框架的学习，一知半解滥竽充数没有用。
#8
ui层要尽量少跟低层次的业务对象做接口设计，仅此而已。
#9
大道至简
#10
刚好符合需求的
#11
学习
#12
2、能在客户端实现的不要写在cs里面。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
这条，如果是安全的话。在客户端和服务器端都要实现。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
这条，如果是安全的话。在客户端和服务器端都要实现。
#13
没有专业只有好用。
管他37二十一呢！先写几个东东出来，然后在慢慢回味，找到自己的感觉。
to sp1234
IdomainObject
这个东东对你来说好像是轻车熟路地，但是本人才疏学浅，一点都没有看懂。
还望赐教。
也许我应该找本这方面基础的书看看了。（你也会这么对我说吧？）
管他37二十一呢！先写几个东东出来，然后在慢慢回味，找到自己的感觉。
to sp1234
IdomainObject
这个东东对你来说好像是轻车熟路地，但是本人才疏学浅，一点都没有看懂。
还望赐教。
也许我应该找本这方面基础的书看看了。（你也会这么对我说吧？）
#14
找到真正适合你所要搞的项目的构架才是“专业构架”
对于有的项目（有的很小、不需要在修改），你搞个三层，浪费时间（没有三层的时候可能半天就搞好了，如果搞了三层，你可能就是一天半了！）
但对于一些，特别是“产品”，你必须有合理的构架，这样后续的添加新功能、修改、处错都非常方便
对于有的项目（有的很小、不需要在修改），你搞个三层，浪费时间（没有三层的时候可能半天就搞好了，如果搞了三层，你可能就是一天半了！）
但对于一些，特别是“产品”，你必须有合理的构架，这样后续的添加新功能、修改、处错都非常方便
#15
怎样才算分层？
层与层之间必须用桥接，我现在还没看见谁愿意去写那么多Provider和Interface。
三层架构的优势在哪里？
如果逻辑层相对稳定，数据储存和用户界面可以自行演化，So，业务逻辑不稳定的项目根本就不适合三层架构，
层与层之间必须用桥接，我现在还没看见谁愿意去写那么多Provider和Interface。
三层架构的优势在哪里？
如果逻辑层相对稳定，数据储存和用户界面可以自行演化，So，业务逻辑不稳定的项目根本就不适合三层架构，
#16
楼主上面说的几个好像都不一定会得到优秀的架构。
如果对这方面感兴趣可以看看MSDN上patterns and practise的文章
有空可以多看看开源项目的设计尤其是Castle、Community Server等
如果对这方面感兴趣可以看看MSDN上patterns and practise的文章
有空可以多看看开源项目的设计尤其是Castle、Community Server等
#17
sorry 我还没有遇到过 “业务逻辑稳定” 的项目呢！
另外写一个业务逻辑稳定（或者叫做“强大”）的东东并非易事！
业务逻辑 是否稳定 都是要有一定的分层的，（分层的思路，而不一定是三层的模式！）
本来嘛，代码后置，就是一种分层；ADO.net 也可以说是一种分层。
另外写一个业务逻辑稳定（或者叫做“强大”）的东东并非易事！
业务逻辑 是否稳定 都是要有一定的分层的，（分层的思路，而不一定是三层的模式！）
本来嘛，代码后置，就是一种分层；ADO.net 也可以说是一种分层。
#18
webform需要再分吗?
#19
sorry 我还没有遇到过 “业务逻辑稳定” 的项目呢！
另外写一个业务逻辑稳定（或者叫做“强大”）的东东并非易事！
业务逻辑 是否稳定 都是要有一定的分层的，（分层的思路，而不一定是三层的模式！）
本来嘛，代码后置，就是一种分层；ADO.net 也可以说是一种分层。
================================================
这样说也是对的……，另一种意义上的分层。
另外写一个业务逻辑稳定（或者叫做“强大”）的东东并非易事！
业务逻辑 是否稳定 都是要有一定的分层的，（分层的思路，而不一定是三层的模式！）
本来嘛，代码后置，就是一种分层；ADO.net 也可以说是一种分层。
================================================
这样说也是对的……，另一种意义上的分层。
#20
看看 PETSHOP/Duwamish7/Rainbow等等
#21
#1
这四条与架构好像都没有关系。
#2
表示层就是你的 aspx, html, css, js
业务层就是处理业务逻辑关系, 比如折扣算法, 验证规则, 还有就是把数据层提供的数据转换成表示层直接可用或可绑的规格
数据层就是访问数据库.
以上是我对分层的肤浅理解. 楼主装装VS2003里的Duwamish7看看吧
业务层就是处理业务逻辑关系, 比如折扣算法, 验证规则, 还有就是把数据层提供的数据转换成表示层直接可用或可绑的规格
数据层就是访问数据库.
以上是我对分层的肤浅理解. 楼主装装VS2003里的Duwamish7看看吧
#3
比如说你的第三条，如果所有的它们都有这样的接口就是专业的：
public interface ImyUI
{
IdomainObject obj{set};
event EventHandler onObjChanged;
}
其中，IdomainObject 是所有业务类型都具有的接口。
这个就应该算初步比较专业的UI层了。
把所有有关UI的函数、方法，全都组织在一个dll里，这是方法库的结构化思路，是很笨拙地甚至错误地理解“分层”这个概念的结果，根本不是面向对象的分层。
public interface ImyUI
{
IdomainObject obj{set};
event EventHandler onObjChanged;
}
其中，IdomainObject 是所有业务类型都具有的接口。
这个就应该算初步比较专业的UI层了。
把所有有关UI的函数、方法，全都组织在一个dll里，这是方法库的结构化思路，是很笨拙地甚至错误地理解“分层”这个概念的结果，根本不是面向对象的分层。
#4
再进一步解释一下上面的，比如说你的一个负责显示数据编辑的控件，它根据IdomainObject类型的参数产生界面元素，就像 vs 开发环境的属性编辑器一样根据对象自动产生每一个属性的编辑条，那么你这个控件就是成功的。
再大的系统，常用的控件也不过几个、十几个，剩下的就是业务逻辑设计。
再大的系统，常用的控件也不过几个、十几个，剩下的就是业务逻辑设计。
#5
上面所说的“常用的控件”是指构造 业务对象UI表现层 的控件，不是指那些底层的textbox等砖头瓦块。
其实很多人言必“分层”，但是并不知道如何分层才不芜杂。
其实很多人言必“分层”，但是并不知道如何分层才不芜杂。
#6
本来写了一大堆，结果CSDN告诉我：
请不要发表可能给我们带来伤害的言论，谢谢配合
还把我所有的文字都给弄丢了……
郁闷……
算了，简而言之。
任何一种架构和设计，都是为了更好的开发效率和适应今后的需求，有其适用场景，与设计模式一样，不要为了模式而模式，更不要为了架构而架构……
请不要发表可能给我们带来伤害的言论，谢谢配合
还把我所有的文字都给弄丢了……
郁闷……
算了，简而言之。
任何一种架构和设计，都是为了更好的开发效率和适应今后的需求，有其适用场景，与设计模式一样，不要为了模式而模式，更不要为了架构而架构……
#7
我说“IdomainObject 是所有业务类型都具有的接口”，如果你不仔细看这个“所有”二字，就会错误理解我的本来意思。
对框架的学习，一知半解滥竽充数没有用。
对框架的学习，一知半解滥竽充数没有用。
#8
ui层要尽量少跟低层次的业务对象做接口设计，仅此而已。
#9
大道至简
#10
刚好符合需求的
#11
学习
#12
2、能在客户端实现的不要写在cs里面。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
这条，如果是安全的话。在客户端和服务器端都要实现。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
这条，如果是安全的话。在客户端和服务器端都要实现。
#13
没有专业只有好用。
管他37二十一呢！先写几个东东出来，然后在慢慢回味，找到自己的感觉。
to sp1234
IdomainObject
这个东东对你来说好像是轻车熟路地，但是本人才疏学浅，一点都没有看懂。
还望赐教。
也许我应该找本这方面基础的书看看了。（你也会这么对我说吧？）
管他37二十一呢！先写几个东东出来，然后在慢慢回味，找到自己的感觉。
to sp1234
IdomainObject
这个东东对你来说好像是轻车熟路地，但是本人才疏学浅，一点都没有看懂。
还望赐教。
也许我应该找本这方面基础的书看看了。（你也会这么对我说吧？）
#14
找到真正适合你所要搞的项目的构架才是“专业构架”
对于有的项目（有的很小、不需要在修改），你搞个三层，浪费时间（没有三层的时候可能半天就搞好了，如果搞了三层，你可能就是一天半了！）
但对于一些，特别是“产品”，你必须有合理的构架，这样后续的添加新功能、修改、处错都非常方便
对于有的项目（有的很小、不需要在修改），你搞个三层，浪费时间（没有三层的时候可能半天就搞好了，如果搞了三层，你可能就是一天半了！）
但对于一些，特别是“产品”，你必须有合理的构架，这样后续的添加新功能、修改、处错都非常方便
#15
怎样才算分层？
层与层之间必须用桥接，我现在还没看见谁愿意去写那么多Provider和Interface。
三层架构的优势在哪里？
如果逻辑层相对稳定，数据储存和用户界面可以自行演化，So，业务逻辑不稳定的项目根本就不适合三层架构，
层与层之间必须用桥接，我现在还没看见谁愿意去写那么多Provider和Interface。
三层架构的优势在哪里？
如果逻辑层相对稳定，数据储存和用户界面可以自行演化，So，业务逻辑不稳定的项目根本就不适合三层架构，
#16
楼主上面说的几个好像都不一定会得到优秀的架构。
如果对这方面感兴趣可以看看MSDN上patterns and practise的文章
有空可以多看看开源项目的设计尤其是Castle、Community Server等
如果对这方面感兴趣可以看看MSDN上patterns and practise的文章
有空可以多看看开源项目的设计尤其是Castle、Community Server等
#17
sorry 我还没有遇到过 “业务逻辑稳定” 的项目呢！
另外写一个业务逻辑稳定（或者叫做“强大”）的东东并非易事！
业务逻辑 是否稳定 都是要有一定的分层的，（分层的思路，而不一定是三层的模式！）
本来嘛，代码后置，就是一种分层；ADO.net 也可以说是一种分层。
另外写一个业务逻辑稳定（或者叫做“强大”）的东东并非易事！
业务逻辑 是否稳定 都是要有一定的分层的，（分层的思路，而不一定是三层的模式！）
本来嘛，代码后置，就是一种分层；ADO.net 也可以说是一种分层。
#18
webform需要再分吗?
#19
sorry 我还没有遇到过 “业务逻辑稳定” 的项目呢！
另外写一个业务逻辑稳定（或者叫做“强大”）的东东并非易事！
业务逻辑 是否稳定 都是要有一定的分层的，（分层的思路，而不一定是三层的模式！）
本来嘛，代码后置，就是一种分层；ADO.net 也可以说是一种分层。
================================================
这样说也是对的……，另一种意义上的分层。
另外写一个业务逻辑稳定（或者叫做“强大”）的东东并非易事！
业务逻辑 是否稳定 都是要有一定的分层的，（分层的思路，而不一定是三层的模式！）
本来嘛，代码后置，就是一种分层；ADO.net 也可以说是一种分层。
================================================
这样说也是对的……，另一种意义上的分层。
#20
看看 PETSHOP/Duwamish7/Rainbow等等