Question

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

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

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

编辑1：我不仅在寻找模式（如Toran Billups指出的那样），还有目录结构，项目结构（如VisualStudio项目）和文档结构。< / p>

Answer 1

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

我发现创建一个类库来保存这个与UI无关的代码可以很容易地重用这段代码。如果采用该路由，此体系结构也适用于简单的Web服务转换，因为您的类库中的服务输入/输出应与Web服务（WCF或ASMX）中的相同;

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

Answer 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适用于您购买或下载的外部物品，但您无法自行构建。

是否有针对.NET和/或ASP.NET项目的推荐，建议或传统结构？

2 个答案: