62,046
社区成员
发帖
与我相关
我的任务
分享第一次用asp.net做项目，有几个问题很不清晰，真心希望得到帮助
问题比较多，因为我好多概念都不清晰，希望得到答复。
第一个 关于系统分层
看微软的petshop层次划分很精细，不知道这样开发回不会引起工作量加大？
我以前通常的都是UI--实体--数据库
第二个 关于DA层
公司里两个牛人给我两种答案
1 实体层不能直接访问数据库，也就是不能有sql和存储过程名
实体层访问DA层通过DA层访问数据库
第三个 关于存储过程和面向对象
我喜欢吧所有的数据库操作封装为存储过程
但这个时候设计师后的对象划分似乎意义不是很大了
而且吧钱太需要的数据库操作封装后
面向对象的应用不是很好了
第四个 完全的面向对象是否会影响效率
看有人的例子 返回一组人 创建了多个人的实例
和返回datatable是否会效率降低，这个效率降低是否可以呼罗不机
第五个 我用的列表大都不需要编辑功能，
我用datarepeater自定义可以分页的控件 是否会
比datagrid性能提高？？ 我看petshop是这样做的。
第一个 关于系统分层
看微软的petshop层次划分很精细，不知道这样开发回不会引起工作量加大？
我以前通常的都是UI--实体--数据库
第二个 关于DA层
公司里两个牛人给我两种答案
1 实体层不能直接访问数据库，也就是不能有sql和存储过程名
实体层访问DA层通过DA层访问数据库
第三个 关于存储过程和面向对象
我喜欢吧所有的数据库操作封装为存储过程
但这个时候设计师后的对象划分似乎意义不是很大了
而且吧钱太需要的数据库操作封装后
面向对象的应用不是很好了
第四个 完全的面向对象是否会影响效率
看有人的例子 返回一组人 创建了多个人的实例
和返回datatable是否会效率降低，这个效率降低是否可以呼罗不机
第五个 我用的列表大都不需要编辑功能，
我用datarepeater自定义可以分页的控件 是否会
比datagrid性能提高？？ 我看petshop是这样做的。
...全文
请发表友善的回复…
发表回复
milchcow 2003-06-29
- 打赏
- 举报
收藏
nittystone 2003-06-29
- 打赏
- 举报
>>>>第一个 关于系统分层
>>>>看微软的petshop层次划分很精细，不知道这样开发回不会引起工作量加大？
工作量当然会增大，如果你只想完成一个项目完事则另当别论，否则你需要考虑到简化系统的复杂性，将来维护，升级，扩缩等因素，所以最好要用多层
@@ 收到 明白
>>>>第二个 关于DA层
所有的数据库操作应该通过DA层完全，你可以采用微软的Data Application Blocks来简化操作:
http://msdn.microsoft.com/library/en-us/dnbda/html/daab-rm.asp?frame=true
@@@@ 恩 以前 我使用sqlhelp直接当作da层的，然后再实体层里写sqlhelp的调用传递数据库的参数（存储过程名和参数）
你的意思是不是，把sql和存储过程名和sqlhelp封装到da层？
>>>>第三个 关于存储过程和面向对象
>>>> 我喜欢吧所有的数据库操作封装为存储过程
存储过程是好东西，为包装/性能而论，应该采用，除非你需要考虑使用其他数据库，但如果你有Data Access层，要改数据库也只要改动Data Access层，其它层就不用改动了
但在实际应用中，你不妨用DataSet的方式传输数据，因为实践上DataSet已经不属於严格意义上的Data Acccess层，而是一种有效的普通数据结构
@@@@@ 恩我都使用dataset返回的，为了统一，甚至返回一个值都返回一个dataset
这样做的影响是否很大？或者是不合理？
>>>>第四个 完全的面向对象是否会影响效率
当然会，因为indirection多了，就象前面说的，如果你只是为了完成项目，你什么都不用考虑，你都可以用procedural programming，但系统复杂了呢？
@@@@@ ") 还是不完全理解...:(
>>>>第五个 我用的列表大都不需要编辑功能，
>>>> 我用datarepeater自定义可以分页的控件 是否会
>>>> 比datagrid性能提高？？ 我看petshop是这样做的。
应该是吧，因为DataGrid比较重，ViewState也大，不过建议你两个都试验一下，测量生成的HTML编码量/服务器所用时间等等
@@@@@@ 嗯我测试一下
真的很感谢！。。
>>>>看微软的petshop层次划分很精细，不知道这样开发回不会引起工作量加大？
工作量当然会增大，如果你只想完成一个项目完事则另当别论，否则你需要考虑到简化系统的复杂性，将来维护，升级，扩缩等因素，所以最好要用多层
@@ 收到 明白
>>>>第二个 关于DA层
所有的数据库操作应该通过DA层完全，你可以采用微软的Data Application Blocks来简化操作:
http://msdn.microsoft.com/library/en-us/dnbda/html/daab-rm.asp?frame=true
@@@@ 恩 以前 我使用sqlhelp直接当作da层的，然后再实体层里写sqlhelp的调用传递数据库的参数（存储过程名和参数）
你的意思是不是，把sql和存储过程名和sqlhelp封装到da层？
>>>>第三个 关于存储过程和面向对象
>>>> 我喜欢吧所有的数据库操作封装为存储过程
存储过程是好东西，为包装/性能而论，应该采用，除非你需要考虑使用其他数据库，但如果你有Data Access层，要改数据库也只要改动Data Access层，其它层就不用改动了
但在实际应用中，你不妨用DataSet的方式传输数据，因为实践上DataSet已经不属於严格意义上的Data Acccess层，而是一种有效的普通数据结构
@@@@@ 恩我都使用dataset返回的，为了统一，甚至返回一个值都返回一个dataset
这样做的影响是否很大？或者是不合理？
>>>>第四个 完全的面向对象是否会影响效率
当然会，因为indirection多了，就象前面说的，如果你只是为了完成项目，你什么都不用考虑，你都可以用procedural programming，但系统复杂了呢？
@@@@@ ") 还是不完全理解...:(
>>>>第五个 我用的列表大都不需要编辑功能，
>>>> 我用datarepeater自定义可以分页的控件 是否会
>>>> 比datagrid性能提高？？ 我看petshop是这样做的。
应该是吧，因为DataGrid比较重，ViewState也大，不过建议你两个都试验一下，测量生成的HTML编码量/服务器所用时间等等
@@@@@@ 嗯我测试一下
真的很感谢！。。
saucer 2003-06-29
- 打赏
- 举报
>>>>第一个 关于系统分层
>>>>看微软的petshop层次划分很精细，不知道这样开发回不会引起工作量加大？
工作量当然会增大，如果你只想完成一个项目完事则另当别论，否则你需要考虑到简化系统的复杂性，将来维护，升级，扩缩等因素，所以最好要用多层
>>>>第二个 关于DA层
所有的数据库操作应该通过DA层完全，你可以采用微软的Data Application Blocks来简化操作:
http://msdn.microsoft.com/library/en-us/dnbda/html/daab-rm.asp?frame=true
>>>>第三个 关于存储过程和面向对象
>>>> 我喜欢吧所有的数据库操作封装为存储过程
存储过程是好东西，为包装/性能而论，应该采用，除非你需要考虑使用其他数据库，但如果你有Data Access层，要改数据库也只要改动Data Access层，其它层就不用改动了
但在实际应用中，你不妨用DataSet的方式传输数据，因为实践上DataSet已经不属於严格意义上的Data Acccess层，而是一种有效的普通数据结构
>>>>第四个 完全的面向对象是否会影响效率
当然会，因为indirection多了，就象前面说的，如果你只是为了完成项目，你什么都不用考虑，你都可以用procedural programming，但系统复杂了呢？
>>>>第五个 我用的列表大都不需要编辑功能，
>>>> 我用datarepeater自定义可以分页的控件 是否会
>>>> 比datagrid性能提高？？ 我看petshop是这样做的。
应该是吧，因为DataGrid比较重，ViewState也大，不过建议你两个都试验一下，测量生成的HTML编码量/服务器所用时间等等
>>>>看微软的petshop层次划分很精细，不知道这样开发回不会引起工作量加大？
工作量当然会增大，如果你只想完成一个项目完事则另当别论，否则你需要考虑到简化系统的复杂性，将来维护，升级，扩缩等因素，所以最好要用多层
>>>>第二个 关于DA层
所有的数据库操作应该通过DA层完全，你可以采用微软的Data Application Blocks来简化操作:
http://msdn.microsoft.com/library/en-us/dnbda/html/daab-rm.asp?frame=true
>>>>第三个 关于存储过程和面向对象
>>>> 我喜欢吧所有的数据库操作封装为存储过程
存储过程是好东西，为包装/性能而论，应该采用，除非你需要考虑使用其他数据库，但如果你有Data Access层，要改数据库也只要改动Data Access层，其它层就不用改动了
但在实际应用中，你不妨用DataSet的方式传输数据，因为实践上DataSet已经不属於严格意义上的Data Acccess层，而是一种有效的普通数据结构
>>>>第四个 完全的面向对象是否会影响效率
当然会，因为indirection多了，就象前面说的，如果你只是为了完成项目，你什么都不用考虑，你都可以用procedural programming，但系统复杂了呢？
>>>>第五个 我用的列表大都不需要编辑功能，
>>>> 我用datarepeater自定义可以分页的控件 是否会
>>>> 比datagrid性能提高？？ 我看petshop是这样做的。
应该是吧，因为DataGrid比较重，ViewState也大，不过建议你两个都试验一下，测量生成的HTML编码量/服务器所用时间等等
fordfamily 2003-06-29
- 打赏
- 举报
up
nittystone 2003-06-29
- 打赏
- 举报
saucer老大 能否指出我上面的概念那些是错误的？
nittystone 2003-06-29
- 打赏
- 举报
thanks
saucer 2003-06-29
- 打赏
- 举报
suggest you read the following architecture level article
Application Architecture for .NET: Designing Applications and Services
http://msdn.microsoft.com/library/en-us/dnbda/html/distapp.asp?frame=true
or its pdf version
http://microsoft.com/downloads/details.aspx?FamilyId=A08E4A09-7AE3-4942-B466-CC778A3BAB34&displaylang=en
Application Architecture for .NET: Designing Applications and Services
http://msdn.microsoft.com/library/en-us/dnbda/html/distapp.asp?frame=true
or its pdf version
http://microsoft.com/downloads/details.aspx?FamilyId=A08E4A09-7AE3-4942-B466-CC778A3BAB34&displaylang=en
nittystone 2003-06-29
- 打赏
- 举报
第二个 关于DA层
公司里两个牛人给我两种答案
1 实体层不能直接访问数据库，也就是不能有sql和存储过程名
实体层访问DA层通过DA层访问数据库
2 实体层直接访问数据库是一个好习惯，（可以避免一些错误的发生）
公司里两个牛人给我两种答案
1 实体层不能直接访问数据库，也就是不能有sql和存储过程名
实体层访问DA层通过DA层访问数据库
2 实体层直接访问数据库是一个好习惯，（可以避免一些错误的发生）
ameng_2002 2003-06-29
- 打赏
- 举报
学习...
第四个 完全的面向对象是否会影响效率
返回一组人 创建了多个人的实例和返回datatable是否会效率降低。。。
业务实体的选择要考虑到几个方面：
1、是否需要把业务实体数据与 Microsoft Windows® 窗体或 ASP.NET 页面中的控件绑定在一起？
2、是否需要对业务实体数据执行排序或搜索操作？
应用程序是每次处理一个业务实体，还是通常处理一组业务实体？
3、是本地部署还是远程部署应用程序？
4、XML Web services 是否使用该业务实体？
5、性能、可缩放性、可维护性、编程方便性等非功能性要求的重要程度如何？
各业务实体的优缺点：
1、XML。使用 XML 字符串或 XML 文档对象模型 (DOM) 对象来表示业务实体数据。XML 是一种开放而灵活的数据表示格式，可用于集成各种类型的应用程序。
2、DataSet。DataSet 是缓存在内存中的表，它是从关系数据库或 XML 文档中获得的。数据访问逻辑组件可以使用 DataSet 来表示从数据库中检索到的业务实体数据，您可以在应用程序中使用该 DataSet。有关 DataSet 的介绍，请参阅 .NET Data Access Architecture Guide 中的“Introducing ADO.NET”。
3、有类型的 DataSet。有类型的 DataSet 是从 ADO.NET DataSet 类继承而来的类，它为访问表和 DataSet 中的列提供了具有严格类型的方法、事件和属性。
4、业务实体组件。这是一种自定义类，用于表示各种业务实体类型。您可以定义保存业务实体数据的字段，并定义将此数据向客户端应用程序公开的属性，然后使用在该类中定义的字段来定义方法以封装简单的业务逻辑。此选项并不通过 CRUD 方法实现与基础数据访问逻辑组件的数据传递，而是通过客户端应用程序直接与数据访问逻辑组件进行通信以执行 CRUD 操作。
5、带有 CRUD 行为的业务实体组件。按上述方法定义一个自定义实体类，并实现调用与此业务实体相关联的基础数据访问逻辑组件的 CRUD 方法。
第四个 完全的面向对象是否会影响效率
返回一组人 创建了多个人的实例和返回datatable是否会效率降低。。。
业务实体的选择要考虑到几个方面：
1、是否需要把业务实体数据与 Microsoft Windows® 窗体或 ASP.NET 页面中的控件绑定在一起？
2、是否需要对业务实体数据执行排序或搜索操作？
应用程序是每次处理一个业务实体，还是通常处理一组业务实体？
3、是本地部署还是远程部署应用程序？
4、XML Web services 是否使用该业务实体？
5、性能、可缩放性、可维护性、编程方便性等非功能性要求的重要程度如何？
各业务实体的优缺点：
1、XML。使用 XML 字符串或 XML 文档对象模型 (DOM) 对象来表示业务实体数据。XML 是一种开放而灵活的数据表示格式，可用于集成各种类型的应用程序。
2、DataSet。DataSet 是缓存在内存中的表，它是从关系数据库或 XML 文档中获得的。数据访问逻辑组件可以使用 DataSet 来表示从数据库中检索到的业务实体数据，您可以在应用程序中使用该 DataSet。有关 DataSet 的介绍，请参阅 .NET Data Access Architecture Guide 中的“Introducing ADO.NET”。
3、有类型的 DataSet。有类型的 DataSet 是从 ADO.NET DataSet 类继承而来的类，它为访问表和 DataSet 中的列提供了具有严格类型的方法、事件和属性。
4、业务实体组件。这是一种自定义类，用于表示各种业务实体类型。您可以定义保存业务实体数据的字段，并定义将此数据向客户端应用程序公开的属性，然后使用在该类中定义的字段来定义方法以封装简单的业务逻辑。此选项并不通过 CRUD 方法实现与基础数据访问逻辑组件的数据传递，而是通过客户端应用程序直接与数据访问逻辑组件进行通信以执行 CRUD 操作。
5、带有 CRUD 行为的业务实体组件。按上述方法定义一个自定义实体类，并实现调用与此业务实体相关联的基础数据访问逻辑组件的 CRUD 方法。
nittystone 2003-06-29
- 打赏
- 举报
下周就开始设计了
作完后我再来请教
mark
再次感谢 (saucer 思归)
我们公司不允许post信息。所以我上班时间不能登陆csdn
我在这儿提的的问题不多，但其中友好大部分都是你解决的
作完后我再来请教
mark
再次感谢 (saucer 思归)
我们公司不允许post信息。所以我上班时间不能登陆csdn
我在这儿提的的问题不多，但其中友好大部分都是你解决的
saucer 2003-06-29
- 打赏
- 举报
>>>你的意思是不是，把sql和存储过程名和sqlhelp封装到da层？
对，起码我是这么做的
>>>@@@@@ 恩我都使用dataset返回的，为了统一，甚至返回一个值都返回一个dataset
>>>这样做的影响是否很大？或者是不合理？
返回一个值都返回一个dataset???当然有影响，DataSet是不小的数据结构，看具体情形吧，你可以返回一个值，或ArrayList,....
>>>@@@@@ ") 还是不完全理解...:(
OO的风行，是因为它比procedural programming更能对付复杂的系统，但它的风格是离problem domain近了，比之于象C语言这样的procedural programming，它离机器又远了
一层，即多了indirection
对，起码我是这么做的
>>>@@@@@ 恩我都使用dataset返回的，为了统一，甚至返回一个值都返回一个dataset
>>>这样做的影响是否很大？或者是不合理？
返回一个值都返回一个dataset???当然有影响，DataSet是不小的数据结构，看具体情形吧，你可以返回一个值，或ArrayList,....
>>>@@@@@ ") 还是不完全理解...:(
OO的风行，是因为它比procedural programming更能对付复杂的系统，但它的风格是离problem domain近了，比之于象C语言这样的procedural programming，它离机器又远了
一层，即多了indirection
