大中型项目的结构

本文关键字：结构 大中型项目 | 更新日期: 2023-09-27 18:31:23

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

由于来自python背景，创建只有几个类的小项目，我大部分时间都会将所有代码放在一个文件中。

我

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

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

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

另外，我是否以正确的方式构建了我的代码？

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

提前非常感谢。

大中型项目的结构

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

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

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

让我试着进一步说明这个例子。

  • 项目：A.通用（组件名称）
  • 用途：任何项目的可重用类型
  • 命名空间：A、A.数据访问
  • 类型： A.DataAccess.DataAccessObjectBase
  • 项目：A.B（组件名称）
  • 用途：产品"B"的类型
  • 参考资料： A.通讯
    • 命名空间：A、A.B
  • 、A.B.DataAccess
  • 类型： A.B.DataAccess.DataAccessObject （实现 A.DataAccess.DataAccessObjectBase）
  • 项目：交流电（装配名称）
  • 用途：产品"C"的类型
  • 参考资料： A.常见
    • 命名空间：A、A.C
  • 、A.C.DataAccess
  • 类型：A.C.DataAccess.DataAccessObject （implements A.DataAccess.DataAccessObjectBase）

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

其他一些提示：

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

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

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

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

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

3）不确定你问的关于将代码拼凑在一起的问题。 你的意思是如何在Visual Studio中物理引用/链接项目，还是最佳实践来编码/访问你的API？ 如果是前者，则可以右键单击项目下的"引用"项并指向该项目（而不是其编译的 DLL）。 如果是后者，您可以遵循多种编程模式，但通常您需要从项目中抽象出一个不错的 API，这样您就不会关心代码的内部工作原理。

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

这是另一个StackOverflow问题，它涉及可能的解决方案结构： 解决方案：每个应用程序或每个应用程序套件

命名空间

可帮助您组织代码并提供关注点分离。也可以通过创建文件夹或单独的项目来完成。通过良好的逻辑分离，您可以构建可维护且可扩展的应用程序。

当您决定是创建新文件夹还是新项目时，您应该依靠常识。例如，为 hello world 应用程序创建多个项目是矫枉过正的。为单个类创建文件夹也是矫枉过正。但是，当您有多个彼此密切相关的类时，请考虑将此特定问题与其他应用程序分开。例如，如果您有CustomerRepository，则添加OrderRepository和VendorRepository。强调他们所代表的关切是很好的决定。创建Repositories文件夹并将所有这些类移动到该文件夹中。

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

FooCompany.BLL
FooCOmpany.DAL
FooCOmpany.UI

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

// 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

顺便说一句，通常的做法是用您正在开发的公司名称开始命名空间名称。请参阅命名空间命名准则。这允许避免在不同命名空间中有两个同名的类时的名称冲突。

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

using System;
using namespace1; 
using namespace2;
相关文章：