这可能是一个广泛的问题，因为部分问题是我实际上不知道问题是什么。我想知道的是，您通常如何根据页面放置 (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. 我留下这个类（没有代码会去那里），但创建一个子类，比如 in MyApp.SomeNamespace.SomeSubNamespace.MyPage，继承自MyApp.MyPage. 这种方式MyApp.SomeNamespace.SomeSubNamespace.MyPage将访问与服务器控件相对应的自动生成的受保护字段MyApp.MyPage我将为与此页面相关的所有支持类获得一个完整的“私有”命名空间。有什么大的缺点吗？另一个困扰我的相关问题是这个新的cs文件应该放在哪里？在 web 项目中，有一个名为 App_Code 的标准文件夹，但我对 web 应用程序感兴趣。在应用程序（例如 Code）的根目录中创建目录听起来不太对。