一个大中型项目的结构

我是一个初学者程序员，对任何愚蠢道歉。一个大中型项目的结构

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

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

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

我现在正在舞台上，我想拼凑每个命名空间来构建我的控制台应用程序。我如何去做这件事？

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

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

非常感谢提前。

来源

2012-04-16 Sherlock

如果您可以对项目进行全面的概述，我想我们可以告诉您更多。目的是什么？它是某种进口工具，或者其他什么。也许有人知道一个开源项目应该有类似的结构（即使它有不同的目的），你可以看看它们是如何解决它的。代码组织没有银弹，这一切都归结为优先选择和一些可维护性的最佳实践。根据目的分离是一个很好的做法;-) – 2012-04-16 18:49:21

如果您接受其他一些问题的答案，人们将更有可能回应这一问题。 – 2012-04-16 18:49:28

@Erik - 这是一个由神经网络（显然），训练遗传算法，CSV阅读器，数据前/后处理器和回归分析组成的神经网络。每个人都在自己的名字空间内。 – Sherlock 2012-04-16 18:56:38

当你开始一个命名空间，您通常会使用您的公司或组织名称（如“A”）。如果您有多个产品/项目并且正在为该项目创建代码，那么您需要添加限定符（比如说“B”，“C”等等，这样您将拥有A.B，A.C等）。

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

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

让我试着进一步研究这个例子。

项目：A.Common（集会名）
用途：可重复使用的类型对任何项目
命名空间：A，A.DataAccess
类型：A.DataAccess.DataAccessObjectBase

项目：AB（组件名称）
目的：A.Commmon
命名空间：对于产品 “B”
参考文献类型A，AB，ABDataAccess
类型：ABDataAccess.DataAccessObject（实现A.DataAccess.DataAccessObjectBase）

项目：AC（集会名）
目的：为类型产品 “C”
参考文献：A.Common
命名空间：A，AC，ACDataAccess
类型：ACDataAccess.DataAccessObject（实现A.DataAccess.DataAccessObjectBase）

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

一些其他提示：

不要与创建命名空间太过火，创造深命名空间（如A.B.Something.SomeMoreStuff.EvenMoreStuff）特别是当，除非是明智的。它使你找到事情有点困难。
命名空间应该从更广泛的目的到更狭义的目的。此外，如果您在更广泛的命名空间中使用的命名空间较窄的名称空间中创建类型，请务必将其放在更广泛的命名空间下。例如A.B.Broader.Narrower。

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

来源

2012-04-16 19:15:33 HackedByChinese

这已经清理了我的东西，非常有用的信息 - 非常感谢:) – Sherlock 2012-04-16 19:22:25

非常好的答案！ – 2012-04-16 23:42:12

我将从上一个问题开始到第一个问题。您可以使用位于项目中完全不同目录中的文件。我认为你以正确的方式前进。关于不同的命名空间，您可以使用此代码

using System; 
using namespace1; 
using namespace2;

来源

2012-04-16 18:44:21 Likurg

是的代码我可以说更多 – Likurg 2012-04-16 18:52:41

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

1）不需要让每个唯一的名称空间由其自己的项目表示;如果它有助于组织你的课程，你可以（也可能应该）在同一个项目中有多个子命名空间。就你而言，这听起来像每个人都被编程为自己的独立组件，因此每个项目都是合理的。

2）你将每个类拆分成一个单独的文件是好的，继续这样做。

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

4）你完全可以从一个完全不同的目录引用文件。只需右键单击项目或文件夹，选择“添加 - >现有项目”，然后浏览到该文件。你可能想将其添加为一个“链接”，因此它并不是物理复制文件：http://msdn.microsoft.com/en-us/library/9f4t9t92%28VS.80%29.aspx

这里的另一个StackOverflow的疑问，云比特到可能的解决方案结构：Solution: Per application, or per application suite

来源

2012-04-16 18:58:32

非常好，谢谢你的回应，帮助很多 – Sherlock 2012-04-16 19:00:53

一个大中型项目的结构

回答

相关问题