如何合理规划待开发的asp.net项目（欢迎大家踊跃讨论！）--重点是自定义控件在项目中的应用 jonsonzxw(.net从入门到精通) 可是如果不自己开发控件，那么asp.net和asp比起来还有什么优势可言呢！ 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 自定义控件可以减少很多的开发量，如DataGrid控件，大体代码都是类似的，你就可以考虑使用自定义控件来实现。这要根据你的项目来定了，如果你要做系统重构的话，那么自定义控件就更有用武之地了。因你的这问题太大，不好回答，可细化一点：） sumanden(心头慌，打中张)其实我是想了解一下，在编写asp过程中尽可能使用模块化编程，包含文件，这样便于程序的维护和开发，而在.net中总觉得开发集中在每个独立的页面中，很难实现模块化的功能，代码重复利用性不高，维护也比较麻烦，我看过一些例子，将数据库操作编写一个特定类，直接调用他来操作数据库，我不知道这在.net中是不是具有很大的普遍性！如果不是，那么.net中如何实现代码重复利用的功能呢！ 你可以把代码写为一个DLL，需要的地方直接用就行了。 gOODiDEA(无语)可是我该把那些代码写在类里面，让后生成dll文件调用呢！如果不是可重复利用的代码也这么处理，那不是和写在每页的后台处理页面类似吗？没什么区别！ 建议可以考虑设计一个基于MVC模式下的解决方案其对于你在架构设计上会有相当的指导作用，实践项目中其实施效果还是不错的，再结合前面各位同行的建议应该能满足你的构想； glboy(星毅) 我看过你的这篇东东，你能说说你写这个类是出于什么考虑的吗?http://expert.csdn.net/Expert/topic/1378/1378306.xml?temp=.9725305 这是在我的类库中的一个孤子类，主要是用于封装我在业务逻辑层中存储过程跟数据库的绑定和执行该存储过程；当存储过程的业务逻辑或数据库设计发生变化的时候，我只需要在这个文件所属的DLL文件进行相应更改就可以提供给用户使用了，不涉及到对ASPX页面的任何更改。当然这种方式也是具有一定的适用范围的不知道我的说明是否让你理解了，因为感觉自己在文字的组织上以及条理性方面都不足，：（ 其实还是要提到这么个问题来，就是这样的设计是基于MVC模式的，这样的设计其层次非常清晰，维护也统一。 glboy(星毅)我理解你的意思，不知道你是怎么规划你的。net程序的！有没有实现模块化功能，我总觉得面对对象编程和模块化很难2全，是不是我的概念模糊了？ 给你个文档参考：模型－视图－控制器（MVC）是Xerox PARC在八十年代为编程语言Smalltalk－80发明的一种软件设计模式，至今已被广泛使用。最近几年被推荐为Sun公司J2EE平台的设计模式，并且受到越来越多的使用ColdFusion和PHP的开发者的欢迎。模型－视图－控制器模式是一个有用的工具箱，它有很多好处，但也有一些缺点。MVC如何工作 MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。视图视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它们包括Macromedia Flash和象XHTML，XML/XSL，WML等一些标识语言和Web services.如何处理应用程序的界面变得越来越有挑战性。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。模型模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。例如它可能用象EJBs和ColdFusion Components这样的构件对象来处理数据库。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。控制器控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后用确定用哪个视图来显示模型处理返回的数据。现在我们总结ＭVC的处理过程，首先控制器接收用户的请求，并决定应该调用哪个模型来进行处理，然后模型用业务逻辑来处理用户的请求并返回数据，最后控制器用相应的视图格式化模型返回的数据，并通过表示层呈现给用户。大部分Web应用程序都是用像ASP，PHP，或者CFML这样的过程化语言来创建的。它们将像数据库查询语句这样的数据层代码和像HTML这样的表示层代码混在一起。经验比较丰富的开发者会将数据从表示层分离开来，但这通常不是很容易做到的，它需要精心的计划和不断的尝试。MVC从根本上强制性的将它们分开。尽管构造MVC应用程序需要一些额外的工作，但是它给我们带来的好处是无庸质疑的。首先，最重要的一点是多个视图能共享一个模型，正如我所提及的，现在需要用越来越多的方式来访问你的应用程序。对此，其中一个解决之道是使用MVC，无论你的用户想要Flash界面或是WAP界面；用一个模型就能处理它们。由于你已经将数据和业务规则从表示层分开，所以你可以最大化的重用你的代码了。由于模型返回的数据没有进行格式化，所以同样的构件能被不同界面使用。例如，很多数据可能用HTML来表示，但是它们也有可能要用Macromedia Flash和WAP来表示。模型也有状态管理和数据持久性处理的功能，例如，基于会话的购物车和电子商务过程也能被Flash网站或者无线联网的应用程序所重用。因为模型是自包含的，并且与控制器和视图相分离，所以很容易改变你的应用程序的数据层和业务规则。如果你想把你的数据库从MySQL移植到Oracle，或者改变你的基于RDBMS数据源到LDAP，只需改变你的模型即可。一旦你正确的实现了模型，不管你的数据来自数据库或是LDAP服务器，视图将会正确的显示它们。由于运用MVC的应用程序的三个部件是相互对立，改变其中一个不会影响其它两个，所以依据这种设计思想你能构造良好的松偶合的构件。对我来说，控制器的也提供了一个好处，就是可以使用控制器来联接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。MVC的缺点MVC的缺点是由于它没有明确的定义，所以完全理解MVC并不是很容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。你将不得不花费相当可观的时间去考虑如何将MVC运用到你的应用程序，同时由于模型和视图要严格的分离，这样也给调试应用程序到来了一定的困难。每个构件在使用之前都需要经过彻底的测试。一旦你的构件经过了测试，你就可以毫无顾忌的重用它们了。根据我个人经验，由于我们将一个应用程序分成了三个部件，所以使用MVC同时也意味着你将要管理比以前更多的文件，这一点是显而易见的。这样好像我们的工作量增加了，但是请记住这比起它所能带给我们的好处是不值一提。MVC并不适合小型甚至中等规模的应用程序，花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。MVC是一条创建软件的好途径MVC设计模式是一个很好创建软件的途径，它所提倡的一些原则，像内容和显示互相分离可能比较好理解。但是如果你要隔离模型、视图和控制器的构件，你可能需要重新思考你的应用程序，尤其是应用程序的构架方面。如果你肯接受MVC，并且有能力应付它所带来的额外的工作和复杂性，MVC将会使你的软件在健壮性，代码重用和结构方面上一个新的台阶。--------------------------------------------------------------------结合此模式和项目进行有机的结合，不要完全的参照；再可以参照MS所给出的两个示例，其实有很多相类似的处理值得借鉴。GOOD LUCK TO YOU！ glboy(星毅)受益匪浅！我想这就是大家经常说的三层架构，在asp里我可以很好的理解mvc不过，我觉得asp.net并不是对asp做简单的补充完善，作为一种面对对象的编程语言，和asp比起来2者相差实在太大！难道.net也能实现MVC设计模式？ MVC好象被JAVA运用的淋漓尽致,但这些理论性的东东如何才能转化成现实的玩艺呢?开发模块化程序,我与楼主也有同感,不知将哪些东东做成模块化,如果连不是很经常重用的东东都写成模块化的,那不是又和写页面代码是一个意思了吗,可能还是对自定义控件的内含没有真正理解透,才导致不能灵活运用的,欢迎继续讨论 生成一个 .ascx 文件 放置 导航菜单 Flash 东东 顺便问一下,哪有基于.net的设计模式的文章(精辟的),我想开开眼 sualtring(VS.NET) .ascx 不是自定义控件，是用户控件！ 具体的实现可参考.NET自带的企业级示例FMStock7和Duwamish cwbboy(好想失恋)那你的通用数据库操作值得是什么？ cwbboy(好想失恋)没用到自定义控件,只是将数据库的操作集中写到一个类中罢了,这是最基本的准则了 自定义控件跟设计模式是两码事自定义控件主要用于特定项目应用，这方面老外做的比较好，你去看看www.csharpcorner.com，www.codeproject的文章和代码就知道,他们对自定义控件的处理和组织方式很值得学习；关于设计模式，个人见解啊，不要丢鸡蛋啊，呵呵.其要求具有一定的面向对象分析设计的基础；.一个好的设计模式可以很好的指导你的项目设计并可实现模式重用和相互搭配工作；.OO的基本原则/OO设计法则才是构成现在谈得很热的各个模式的基础扩展性、伸缩性、可靠性等是软件设计的目标，OO的基本原则/OO设计法则是指导软件设计的基础；推荐：http:\\www.umlchina.comhttp://www.webscope-group.org还有就是《非程序员》也是值得一看的 对楼上cwbboy(好想失恋)的描述理解，数据库操作一般包含有：添加，修改，删除，查询这些基本数据操作；另外一块就是基于具体系统的业务逻辑约束。然后将这部分封装成类进行管理和维护。 好像还没讨论出什么头绪嘛！响应 glboy(星毅)的建议！请大家踊跃发言 关于农行在线支付接口(asp)版问题 怎么样js控制版权始终在页面的最下端 急啊~~留言板回复内容修改问题 如何得到GridView某一列下面的所有值,将值放到Arraylist 未将对象引用设置到对象的实例求解 求c#在线编辑器 最简单的数据库操作.新增记录的问题. asp.net登陆问题，在线等。。 asp.net怎么读取Excel2003中的数据到DataGrid中阿？这不是老问题，很难解决的 大家来帮忙，小弟只有最后50分了，谁答得好，就全部奉献！（在线等待） 奇怪的乱码问题，盼高手解决，100分 我想在一个页面中的DATAGRID选择一些数据，然后在另一页面中显示这些数据，该怎么做
这要根据你的项目来定了，如果你要做系统重构的话，那么自定义控件就更有用武之地了。
因你的这问题太大，不好回答，可细化一点：）
其对于你在架构设计上会有相当的指导作用，实践项目中其实施效果还是不错的，再结合前面各位同行的建议应该能满足你的构想；
http://expert.csdn.net/Expert/topic/1378/1378306.xml?temp=.9725305
当存储过程的业务逻辑或数据库设计发生变化的时候，我只需要在这个文件所属的DLL文件进行相应更改就可以提供给用户使用了，不涉及到对ASPX页面的任何更改。当然这种方式也是具有一定的适用范围的不知道我的说明是否让你理解了，因为感觉自己在文字的组织上以及条理性方面都不足，：（
MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。视图
视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它们包括Macromedia Flash和象XHTML，XML/XSL，WML等一些标识语言和Web services.如何处理应用程序的界面变得越来越有挑战性。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。模型
模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。例如它可能用象EJBs和ColdFusion Components这样的构件对象来处理数据库。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。控制器
控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后用确定用哪个视图来显示模型处理返回的数据。现在我们总结ＭVC的处理过程，首先控制器接收用户的请求，并决定应该调用哪个模型来进行处理，然后模型用业务逻辑来处理用户的请求并返回数据，最后控制器用相应的视图格式化模型返回的数据，并通过表示层呈现给用户。大部分Web应用程序都是用像ASP，PHP，或者CFML这样的过程化语言来创建的。它们将像数据库查询语句这样的数据层代码和像HTML这样的表示层代码混在一起。经验比较丰富的开发者会将数据从表示层分离开来，但这通常不是很容易做到的，它需要精心的计划和不断的尝试。MVC从根本上强制性的将它们分开。尽管构造MVC应用程序需要一些额外的工作，但是它给我们带来的好处是无庸质疑的。首先，最重要的一点是多个视图能共享一个模型，正如我所提及的，现在需要用越来越多的方式来访问你的应用程序。对此，其中一个解决之道是使用MVC，无论你的用户想要Flash界面或是WAP界面；用一个模型就能处理它们。由于你已经将数据和业务规则从表示层分开，所以你可以最大化的重用你的代码了。由于模型返回的数据没有进行格式化，所以同样的构件能被不同界面使用。例如，很多数据可能用HTML来表示，但是它们也有可能要用Macromedia Flash和WAP来表示。模型也有状态管理和数据持久性处理的功能，例如，基于会话的购物车和电子商务过程也能被Flash网站或者无线联网的应用程序所重用。因为模型是自包含的，并且与控制器和视图相分离，所以很容易改变你的应用程序的数据层和业务规则。如果你想把你的数据库从MySQL移植到Oracle，或者改变你的基于RDBMS数据源到LDAP，只需改变你的模型即可。一旦你正确的实现了模型，不管你的数据来自数据库或是LDAP服务器，视图将会正确的显示它们。由于运用MVC的应用程序的三个部件是相互对立，改变其中一个不会影响其它两个，所以依据这种设计思想你能构造良好的松偶合的构件。对我来说，控制器的也提供了一个好处，就是可以使用控制器来联接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。MVC的缺点
MVC的缺点是由于它没有明确的定义，所以完全理解MVC并不是很容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。你将不得不花费相当可观的时间去考虑如何将MVC运用到你的应用程序，同时由于模型和视图要严格的分离，这样也给调试应用程序到来了一定的困难。每个构件在使用之前都需要经过彻底的测试。一旦你的构件经过了测试，你就可以毫无顾忌的重用它们了。根据我个人经验，由于我们将一个应用程序分成了三个部件，所以使用MVC同时也意味着你将要管理比以前更多的文件，这一点是显而易见的。这样好像我们的工作量增加了，但是请记住这比起它所能带给我们的好处是不值一提。MVC并不适合小型甚至中等规模的应用程序，花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。MVC是一条创建软件的好途径
MVC设计模式是一个很好创建软件的途径，它所提倡的一些原则，像内容和显示互相分离可能比较好理解。但是如果你要隔离模型、视图和控制器的构件，你可能需要重新思考你的应用程序，尤其是应用程序的构架方面。如果你肯接受MVC，并且有能力应付它所带来的额外的工作和复杂性，MVC将会使你的软件在健壮性，代码重用和结构方面上一个新的台阶。
--------------------------------------------------------------------结合此模式和项目进行有机的结合，不要完全的参照；
再可以参照MS所给出的两个示例，其实有很多相类似的处理值得借鉴。GOOD LUCK TO YOU！
开发模块化程序,我与楼主也有同感,不知将哪些东东做成模块化,如果连不是很经常重用的东东都写成模块化的,那不是又和写页面代码是一个意思了吗,可能还是对自定义控件的内含没有真正理解透,才导致不能灵活运用的,欢迎继续讨论
自定义控件主要用于特定项目应用，这方面老外做的比较好，你去看看www.csharpcorner.com，www.codeproject的文章和代码就知道,他们对自定义控件的处理和组织方式很值得学习；关于设计模式，个人见解啊，不要丢鸡蛋啊，呵呵
.其要求具有一定的面向对象分析设计的基础；
.一个好的设计模式可以很好的指导你的项目设计并可实现模式重用和相互搭配工作；
.OO的基本原则/OO设计法则才是构成现在谈得很热的各个模式的基础
扩展性、伸缩性、可靠性等是软件设计的目标，OO的基本原则/OO设计法则是指导软件设计的基础；推荐：
http:\\www.umlchina.com
http://www.webscope-group.org
还有就是《非程序员》也是值得一看的