这可能是一个广泛的问题，因为部分问题是我实际上不知道问题是什么。我想知道的是你如何在页面放置（aspx），用户控件（ascx），服务器控件和其他支持类和实用函数等方面组织ASP.NET应用程序。首先，我们假设已经存在一些数据层（可能在不同的项目中）。这不是问题。 我经常遇到的问题是创建几个页面并意识到他们需要共享一些常见的渲染逻辑或一些实用功能，类等。另一个典型的情况是一些页面变得太大，以至于分割它们似乎很方便（比如说一些用户控件）。放置这些实用程序类，共享类，用户控件，服务器控件等的最佳位置是什么？这有几种可能性。
不要真正关心任何组织，并将所有类型的文件放在一起。所以在一个目录中，你可能有一个aspx文件，一些cs文件等。这可能不是一个真正的选择。
按类型整理文件。假设您为用户控件创建了一个目录，并将所有用户控件放在那里。好的，但是服务器控件和其他常规类呢？它们应该也在特殊目录中吗？这听起来不对。我最不喜欢的是当你处理一个特征（逻辑上相关的代码片段）时，你必须在整个地方捕获它。我认为应用程序的功能和逻辑部分也应该以某种方式在文件系统级别上进行分组。
我想要的是让页面（aspx），用户控件（ascx）和处理程序（ashx）基本上作为虚拟占位符坐在目录结构中从逻辑上组织根据外部的观点访问者，而实际代码（页面，用户控件实现，服务控件和实用程序类）应放在结构为逻辑命名空间的不同文件夹中（由应用程序的模块或功能组织）。在我看来，实现这一目标的唯一方法是手动操作<%@ Page ... %>指令。
这听起来很疯狂吗？我问得太多了吗？有没有更好的办法？你最好的做法是什么？你知道一些很好的例子吗？
编辑：另一个想法。这不会搞砸生成的aspx，aspx.cs和aspx.designer.cs文件。我最初的要求之一就是我想将驱动aspx页面的代码放到我自己的位置并将其放到自定义命名空间层次结构中。那么如果我简单地继承VS生成的aspx类呢？假设我有一个名为MyApp和MyPage.aspx页面的项目。然后，VS创建从MyApp.MyPage继承的System.Web.UI.Page。我留下这个类（没有代码会去那里），但是创建一个子类，比如MyApp.SomeNamespace.SomeSubNamespace.MyPage，继承自MyApp.MyPage。这样MyApp.SomeNamespace.SomeSubNamespace.MyPage将访问与MyApp.MyPage的服务器控件相对应的自动生成的受保护字段，并且我将获得与此页面相关的所有支持类的完整“私有”命名空间。有什么主要缺点？困扰我的另一个相关问题是这个新的cs文件应该放在哪里？在Web项目中，有一个名为App_Code的标准文件夹，但我对Web应用程序感兴趣。在应用程序的根目录中创建目录（例如代码）听起来不对。
答案 0 :(得分：4)
请记住，您可以创建实际上与任何标记不对应的页面类。我们经常创建实际UI页面继承的基页。这是组织“基本”页面功能的简单方法。然后，当您创建.aspx页面时，让它们从基页类继承，而不是继承System.Web.UI.Page。
我们通常将基页.cs文件放入顶级目录（如果它是一个小项目），或者对于稍大的项目，我们将创建一个“共享”或类似的目录。
但是，我们还有一个庞大的企业Web项目，我们只是将我们的webcontrols和基页构建到一个名为CompanyName.Web.UI的类库中，其中有几个子命名空间。我们所有的实际网站项目都导入该程序集，控件的所有代码等都在其他地方。听起来这对你来说可能是一个不错的选择。
如果你还记得你的.aspx代码隐藏可以从任何类文件继承，它应该让你更容易组织。