.NET 和/或 ASP.NET 项目是否有推荐的、建议的或常规的结构？答案

【问题标题】：Is there a recommended, suggested, or conventional structure for .NET and/or ASP.NET projects?.NET 和/或 ASP.NET 项目是否有推荐的、建议的或常规的结构？
【发布时间】：2008-11-17 17:37:20
【问题描述】：

我正在考虑开始一个相当大规模的 .NET 或 ASP.NET 项目（我还没有决定，但很可能最终，它可以从两个用 .NET 编写的桌面应用程序访问。 NET 以及 ASP.NET Web 应用程序）。但是，我不确定是否有常规的方式来构建项目。

项目本身是一个资源/知识管理工具，可跟踪许多知识来源——人员、出版物（书籍、期刊、杂志）、网络资源、数字文档（包括 PDF、Word 文档、ODF 文档、MP3 等） ) 和我认为合适的其他人。当然，因为它太大了，我希望能够一次实现和测试一个部分，但将它们集成到一个系统中。

一旦我完成并测试了一两个部分，我想将其作为开源工具发布。但是，如果其他人要为此工作，我想向他们展示一个易于理解的结构。但是，我从来没有参与过 ASP.NET 项目，而且自从 2.0 框架是新的时候，我就没有接触过 .NET。我正在寻找 .NET 社区中存在的任何约定，以及关于如何构建如此大规模的项目以使设计、开发、测试、使用和维护尽可能简单和轻松的任何一般约定使用或参与此项目的任何人。

编辑 1： 我不仅在寻找模式（如 Toran Billups 指出的那样），而且还在寻找目录结构、项目结构（如在 VisualStudio 项目中）和文档结构。

【问题讨论】：

标签： .net asp.net project-management

【解决方案1】：

如果您正在使用 Web 表单技术并希望能够使用相同的代码库创建桌面应用程序，我建议您使用模型视图演示器模式将 UI 与业务编码分开。除了这种方法，我建议创建一个服务层来处理 Presenter 类之外的逻辑（包括数据访问/业务逻辑）。

我发现创建一个类库来保存这个与 UI 无关的代码可以很容易地重用这个代码。如果您采用这种方式，这种架构还有助于实现简单的 Web 服务转换，因为您的服务输入/输出在您的类库中应该与它们在 Web 服务（WCF 或 ASMX）中的相同

我建议 this 来自 MSDN 的优秀文章，作者是伟大的 JP Boodhoo。我遵循相同的结构，最大的好处是我的 UI 不会驱动我的业务线应用程序。它们也更易于维护和重用。我可以让 Web 表单应用程序使用我的 WPF 应用程序使用的相同类库。

【讨论】：

【解决方案2】：

对于代码树布局，我通常会这样做：

projectname/
           /source/
           /source/projectname.sln
           /source/DataAccess/
           /source/DataAccess/DataAccess.csproj
           /database/schema/
           /database/schema/something.sql
           /database/testdata/
           /database/refdata/
           /tools/
           /COTS/
           /COTS/vendorname/
           /COTS/vendorname/somelib.dll
           /doc/
           /build/
           /installer/
           /projectname.build

所以顶级目录包含项目的构建文件。这可以是ant、make等。我们使用FinalBuilder。然后你有每个源、数据库、工具、COTS、doc 等的子目录。你可能会想到其他的，但这些是显而易见的。

我通常包含一个构建文件夹，用于暂存构建的输出。这将是您的安装程序查找其文件的位置。

源代码树的顶部是我的 Visual Studio 解决方案文件。每个子项目都有自己的子目录，其中包含其 vs 项目文件和其他所有内容。我喜欢把东西封装在相当小的项目中，所以我可能在一个解决方案中有 10 个项目，每个项目在源代码下都有自己的子目录。

数据库脚本可以随意分开，但尽量保持结构和数据分开。

工具用于构建此项目所需的杂项。

COTS 适用于您购买或下载的、您依赖但无法自行构建的外部事物。

【讨论】：