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创建MyApp.MyPage继承自System.Web.UI.Page 。我保留这个类(没有代码会去那里)，但创建一个子类，比如 MyApp.SomeNamespace.SomeSubNamespace.MyPage ，继承自MyApp.MyPage 。这边MyApp.SomeNamespace.SomeSubNamespace.MyPage将访问与 MyApp.MyPage 的服务器控件相对应的自动生成的 protected 字段我将获得与此页面相关的所有支持类的完整“私有(private)”命名空间。有什么主要缺点吗？困扰我的另一个相关问题是这个新的 cs 文件应该物理放置在哪里？在 Web 项目中，有一个名为 App_Code 的标准文件夹，但我对 Web 应用程序感兴趣。在应用程序(例如 Code)的根目录中创建目录听起来不太正确。

Answer 1

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

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

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

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