中大型项目的结构答案

【问题标题】：Structure of a Medium-Large scale project中大型项目的结构
【发布时间】：2012-04-28 02:34:50
【问题描述】：

我是一个初学者程序员，为任何愚蠢道歉。

我来自 python 背景创建只有几个类的小项目，大多数时候我会将所有代码放在一个文件中。

我最近一直在学习 c#，并且正在编写一个相当大的控制台应用程序（10,000 行以上）。我显然不能在这里将所有内容都放在一个文件中，但我不确定如何将项目分成更小的部分。

到目前为止，我这样做的方式是为我的解决方案中的每个命名空间创建一个新项目，并将每个类相应地拆分为一个单独的文件。到目前为止，我有大约四个命名空间。我已经独立编写了每个命名空间，以期在其他项目中使用每个命名空间。

我现在正处于一个阶段，我想将每个命名空间拼凑起来以构建我的控制台应用程序。我该怎么做呢？

另外，我的代码结构是否正确？

另外+1，是否可以在项目中使用位于完全不同目录中的文件？

提前非常感谢。

【问题讨论】：

如果您能对您的项目进行广泛的概述，我想我们可以告诉您更多信息。目的是什么？它是某种导入工具，还是其他什么。也许有人知道一个开源项目应该有类似的结构（即使它用于不同的目的），你可以看看他们是如何解决它的。代码组织没有灵丹妙药，这一切都归结为偏好和一些可维护性的最佳实践。按目的分开是一种很好的做法;-)
如果您接受其他一些问题的答案，人们将更有可能回复这个问题。
@Erik - 这是一个由神经网络（显然）、用于训练的遗传算法、csv 阅读器、数据前/后处理器和回归分析组成的神经网络。每一个都在自己的命名空间中。

标签： c# class namespaces

【解决方案1】：

当您从命名空间开始时，您通常会使用您的公司或组织名称（例如“A”）。如果您有多个产品/项目并且正在为该项目创建代码，则您需要添加一个限定符（例如“B”、“C”等，因此您将拥有 AB、AC 等）。

那么一般的方法是您希望在相关的命名空间中将类型组合在一起。如果您创建一个类型并且它是针对常见问题的通用/实用程序/一次性解决方案，您将希望将其保留在范围更广的命名空间中。当您发现您正在创建许多类型以支持某些功能或目的时，您可能希望创建一个狭窄的命名空间来包含这些类型。例如，假设您需要为 A.B 编写几个数据访问组件，其中包含数据传输对象、数据访问对象等。那么您可能希望将这些类型放在 A.B.DataAccess 之类的东西中。

但是，请记住 .NET 使用 OOP 范例。一种 OOP 范式是代码重用。因此，如果您同时访问 A.B 和 A.C 中的数据，您最好创建可重用的数据访问组件以鼓励在两个项目中重用代码。在这种情况下，您可能希望有一个项目，例如 A.Common，其中包含您的任何产品使用的通用类型，其中包含可在 AB、AC 等中使用的通用、通用或抽象概念。

让我试着用这个例子更进一步。

项目：A.Common（程序集名称）
用途：任何项目的可重用类型
命名空间：A、A.DataAccess
类型：A.DataAccess.DataAccessObjectBase

项目：A.B（程序集名称）
用途：产品“B”的类型
参考：A.Common
命名空间：A、A.B、A.B.DataAccess
类型：A.B.DataAccess.DataAccessObject（实现 A.DataAccess.DataAccessObjectBase）

项目：A.C（程序集名称）
用途：产品“C”的类型
参考文献：A.Common
命名空间：A、A.C、A.C.DataAccess
类型：A.C.DataAccess.DataAccessObject（实现 A.DataAccess.DataAccessObjectBase）

这是一个非常简单粗暴的示例，但希望它可以帮助您可视化程序集和命名空间之间的关系。

其他一些提示：

不要过度创建命名空间，尤其是在创建深层命名空间（例如 A.B.Something.SomeMoreStuff.EvenMoreStuff）时，除非它是明智的。这会让你更难找到东西。
命名空间应该从更广泛的用途转向更狭窄的用途。此外，如果您在较窄的命名空间中创建一个类型，该类型严重依赖于较宽命名空间中的内容，请确保将其放在较宽的命名空间下。例如A.B.Broader.Narrower。

最后，您应该继续为每个源文件创建一种类型。

【讨论】：

这让我明白了，非常有用的信息 - 非常感谢 :)

【解决方案2】：

听起来或多或少在正确的轨道上。解决您的问题/结构：

1) 不需要让每个唯一的命名空间都由其自己的项目来表示；如果它有助于组织您的类，您可以（并且可能应该）在同一个项目中拥有多个子命名空间。在您的情况下，听起来每个都被编程为自己的独立组件，因此每个项目都有一个项目是有意义的。

2) 您将每个类拆分为单独的文件很好，请继续这样做。

3) 不确定您要如何将代码拼凑在一起。您的意思是如何在 Visual Studio 中物理引用/链接项目或最佳实践来编码/访问您的 API？如果是前者，可以右击工程下的“References”项，指向工程（不是其编译好的DLL）。如果是后者，您可以遵循多种编程模式，但通常您会希望从项目中抽象出一个不错的 API，这样您就不必担心代码的内部工作。

4) 您绝对可以从完全不同的目录中引用文件。只需右键单击项目或文件夹，选择“添加 -> 现有项目”，然后浏览到该文件。您可能希望将其添加为“链接”，这样它就不会物理复制文件：http://msdn.microsoft.com/en-us/library/9f4t9t92%28VS.80%29.aspx

这是另一个涉及可能的解决方案结构的 StackOverflow 问题：Solution: Per application, or per application suite

【讨论】：

【解决方案3】：

命名空间可帮助您组织代码并提供separation of concerns。它也可以通过创建文件夹或单独的项目来完成。通过良好的逻辑分离，您可以构建可维护和可扩展的应用程序。

当您决定是否创建新文件夹或新项目时，您应该依靠常识。例如，为 hello world 应用程序创建多个项目是一种矫枉过正的做法。为单个班级创建文件夹也太过分了。但是，当您有多个彼此密切相关的类时，请考虑将此特殊关注点与其他应用程序分开。例如。如果您有CustomerRepository，则添加OrderRepository 和VendorRepository。突出他们所代表的关注是一个很好的决定。创建Repositories 文件夹并将所有这些类移到那里。

对于大型应用程序，将业务逻辑、数据访问逻辑和用户界面等关注点分开是很常见的。通常与这些问题相关的类会分到不同的项目中。请记住，这种分离使您的代码更易于理解和维护。因此，命名空间应该向您和任何将维护您的应用程序的人描述关注点。例如。您可以使用三个项目：

FooCompany.BLL
FooCOmpany.DAL
FooCOmpany.UI

那是业务逻辑层、数据访问层和用户界面的首字母缩略词。没有“标准”名称。你可以使用任何能更好地描述你的代码的东西。以下是我通常用于公司 Foo 产品 Bar 的项目结构示例：

// Assembly for business logic
Foo.Bar.Domain
Foo.Bar.Domain.Model
Foo.Bar.Domain.Services
Foo.Bar.Domain.Repositories
// Assembly for data access
Foo.Bar.Persistence.NHibernate 
// Assembly for application services
Foo.Bar.Services
// Project for presentation    
Foo.Bar.Presentation.Web
Foo.Bar.Presentation.Web.Controllers
Foo.Bar.Presentation.Web.Views

顺便说一句，以您正在开发的公司名称开头命名空间名称的常见做法。见Namespace Naming Guidelines。当您在不同的命名空间中有两个具有相同名称的类时，这可以避免名称冲突。

【讨论】：

【解决方案4】：

我将从最后一个问题开始。您可以使用位于项目中完全不同目录中的文件。我认为你走对了。关于不同的命名空间，您可以使用此代码

using System;
using namespace1; 
using namespace2;

【讨论】：