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项目，我们只需将我们的webcontrols和基础页面构建到名为CompanyName.Web.UI的类库中，并具有几个子命名空间。我们所有的实际网站项目导入该程序集和控件的所有代码等都在其他地方。这听起来像它可能是一个很好的选择。

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