ASP.NET 项目组织

Question

这可能是一个广泛的问题，因为部分问题在于我实际上不知道问题是什么。我想知道的是，您通常如何根据页面放置 (aspx)、用户控件 (ascx)、服务器控件和其他支持类和实用程序功能等来组织 ASP.NET 应用程序。首先，假设已经有某处的一些数据层（可能在不同的项目中）。这不是问题。 我经常遇到的问题是创建多个页面并意识到它们需要共享一些通用的渲染逻辑或一些实用程序函数、类等。另一个典型的情况是某些页面变得太大以至于拆分它们看起来很方便（比如分成一些用户控件）。放置这些实用程序类、共享类、用户控件、服务器控件等的最佳位置是什么？这里有几种可能性。

不要真正关心任何组织，并将所有类型的文件放在一起。所以在一个目录中，你可能有一个 aspx 文件，一些 cs 文件等。这可能不是一个真正的选项。

按类型组织文件。假设您为用户控件创建了一个目录并将所有用户控件放在那里。好的，但是服务器控件和其他常规类呢？它们也应该在特殊目录中吗？听起来不对。我最不喜欢的是，当你处理一个特性（逻辑相关的代码）时，你必须到处寻找它。我认为应用程序的功能和逻辑部分也应该以某种方式在文件系统级别进行分组。

我想要的是将页面（aspx）、用户控件（ascx）和处理程序（ashx）基本上作为虚拟占位符，根据外部的观点从逻辑上组织在目录结构中访问者，而实际代码（页面、用户控件实现、服务控件和实用程序类）应放置在结构化为逻辑名称空间（由应用程序的模块或功能组织）的不同文件夹中。在我看来，实现这一点的唯一方法是手动操作 <%@ Page ... %> 指令。

听起来很疯狂吗？我要求太多了吗？有没有更好的办法？你的最佳实践是什么？你知道一些好的例子吗？

编辑：另一个想法。这不会与生成的 aspx、aspx.cs 和 aspx.designer.cs 文件混淆。我最初的要求之一是我想将驱动 aspx 页面的代码放置到我自己的位置，并将其放置到自定义命名空间层次结构中。那么，如果我只是将 VS 生成的 aspx 类作为子类呢？假设我有一个名为 MyApp 的项目和 MyPage.aspx 页面。 VS 然后创建从System.Web.UI.Page 继承的MyApp.MyPage。我留下这个类（没有代码会去那里），但是创建一个子类，比如MyApp.SomeNamespace.SomeSubNamespace.MyPage，继承自MyApp.MyPage。这样MyApp.SomeNamespace.SomeSubNamespace.MyPage 将可以访问与MyApp.MyPage 的服务器控件相对应的自动生成的受保护字段，并且我将获得与此页面相关的所有支持类的完整“私有”命名空间。有什么大的缺点吗？另一个困扰我的相关问题是这个新的cs文件应该物理放置在哪里？在 Web 项目中，有一个名为 App_Code 的标准文件夹，但我对 Web 应用程序感兴趣。在应用程序（例如 Code）的根目录中创建目录听起来不对。

Answer 1

请记住，您可以创建实际上不对应任何标记的页面类。我们经常创建我们的实际 UI 页面继承自的基本页面。这是一种组织“基本”页面功能的简单方法。然后，当您创建 .aspx 页面时，使它们继承自基页面类，而不是 System.Web.UI.Page。

如果它是一个小型项目，我们通常将我们的基本页面 .cs 文件放在顶级目录中，或者对于稍微大一点的项目，我们将在它们所在的位置创建一个“共享”或类似的目录。

但是，我们也有一个庞大的企业 Web 项目，我们只是将 Web 控件和基本页面构建到一个名为 CompanyName.Web.UI 的类库中，并带有几个子命名空间。我们所有的实际网站项目都导入该程序集，并且控件的所有代码等都在其他地方。听起来这对您来说可能是个不错的选择。

如果您记得您的 .aspx 代码隐藏可以从任何类文件继承，它应该会让您更容易组织。