ASP.NET 项目组织

发布于 2024-07-25 20:38:35 字数 1532 浏览 10 评论 0原文

这可能是一个广泛的问题，因为部分问题是我实际上不知道问题是什么。我想知道的是，您通常如何在页面放置（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）的根目录中创建目录听起来不太正确。

原文

This may be a broad question because part of the problem is that I actually don’t know what the question is. What I would like to know is how you commonly organise ASP.NET applications in terms of placement of pages (aspx), user controls (ascx), server controls and other support classes and utility functions etc. First, let’s assume that there is already some data layer somewhere (perhaps in a different project). This is the not issue.
The issue I frequently face is that create several pages and realize that they need to share some common rendering logic or some utility function, class etc. Another typical case is that some pages become too large so that it seems handy to split them (say into some user controls). What is the best place to put these utility classes, share classes, user controls, server control etc.? Here are several possibilities.

Don’t really care about any organisation and place all types of files next to each other. So in one directory, you may have an aspx files, some cs files etc. This is not really an option probably.

Organize files by types. Let’s say you create a directory for user controls and put all user controls there. OK, but what about server controls and other regular classes? Should they be in special directories as well? It does not sound right. What I dislike most on this is that when you work on a feature (logically related piece of code), you must hunt it all over the place. I think that features and logical sections of your applications should be also grouped on the file system level in some way.

What I would like to have is to have the pages (aspx), user controls (ascx) and handlers (ashx) basically as dummy placeholders sitting in the directory structure organized from the logically according to the point of view of the outside visitor while the actual code (page, user controls implementations, serve control and utility classes) should be placed in s different folder structured into logical namespaces (organized by the modules or features of the application). It seems to me that the only way to achieve this is to manipulate the <%@ Page ... %> directive manually.

Does it sound crazy? Am I asking too much? Is there a better way? What are your best practices? Do you know some good examples?

Edit: Another idea. This does not mess up with the generated aspx, aspx.cs and aspx.designer.cs files. One on my original requirements was that I wanted to place the code driving aspx pages to my own location and put it to a custom namespace hierarchy. So what if I simply subclass the aspx classes generated by VS? Let’s say I have a project called MyApp and MyPage.aspx page in it. VS then creates MyApp.MyPage inherited from System.Web.UI.Page. I leave this class be (no code will go there), but create a subclass, say in MyApp.SomeNamespace.SomeSubNamespace.MyPage, inherited from MyApp.MyPage. This way MyApp.SomeNamespace.SomeSubNamespace.MyPage will get access to the autogenerated protected fields corresponding to the server controls of MyApp.MyPage and I’ll get an entire "private" namespace for all the support classes which are related to this page. Any major disadvantages? Another related problem which bothers me is where should this new cs file be physically placed? In web projects, there is a standard folder for it called App_Code, but I’m interested in web applications. Creating a directory in the root of the application (such as Code) does not sound right.