为什么要为应用程序的业务逻辑创建像 Product.Core 这样的子命名空间而不是“根命名空间”产品？答案

【问题标题】：Why to create sub namespace like Product.Core for application's business logic instead of "root namespace" Product?为什么要为应用程序的业务逻辑创建像 Product.Core 这样的子命名空间而不是“根命名空间”产品？
【发布时间】：2017-04-21 07:02:10
【问题描述】：

我想知道为什么最常见的东西/基本逻辑不只是放在 Product 中。创建 Product.Core 并在 Product 中直接放置任何内容只是为了暗示类的真正含义吗？是否有任何“规则”/最佳实践？

这是一个简单的问题，但我不确定我的写作是否有意义。

编辑：如果我在命名空间中有 3 件事要划分：GUI、DataAccess 和业务逻辑，并决定在 3 个命名空间中有类。前 2 个很明显：

产品.UI

Product.DataAccess

但是业务逻辑可以放在其中一个

产品.核心

或

产品

现在我想知道哪个更“标准”：在 Product 或 Product.Core 中具有业务逻辑。

如果将业务逻辑类放在 Product 中，则不会有 Product.Core。

如果将业务逻辑类放在 Product.Core 中，则 Product 将不包含任何类。

这两种方法都有一些好处，我想知道人们的想法。

【问题讨论】：

我认为这个问题的答案会很自以为是。来自 MS：msdn.microsoft.com/en-us/library/ms229026
您从哪里获得这些信息？我经常看到使用“Product”，其他时候使用“Product.Core”
@Kritner：得到什么信息？我没有任何信息。这就是为什么我要问是否有任何最佳实践/常用方法来做到这一点。我也见过。
我并不是在暗示更常见或任何东西，我试图理解/猜测将常见的东西/业务逻辑放入 Product.Core 而不是仅仅将其放入“根”的动机。
等等，你的意思是为什么人们一开始就有一个“深”的命名空间？即：namespace MyCompany.MyProduct vs namespace MyProduct ?

标签： c# oop architecture namespaces

【解决方案1】：

https://softwareengineering.stackexchange.com/questions/40394/how-do-you-organize-your-projects 对此进行了一些很好的讨论。

有一点是为了进一步扩展，尽可能多地分离解决方案 - 但根据需要动态重构通常更容易。否则，分离项目有两个主要原因：

1.遵循关注点分离范式
例如，在一个简单的 Web 项目中，我将有 2 个项目 Project 和 Project.Core。这让我可以将所有数据、逻辑和代码保存在一个项目中，同时将所有 Web 内容保存在另一个项目中。

2。在各个消费者/前端应用程序之间共享代码
例如，如果您计划拥有一个 Web 应用程序和一个 Windows 服务，那么您将在服务和数据访问领域拥有通用代码。您可以将其移动到一个公共库中，而不是复制此代码，以便两个应用程序都可以利用相同的代码。

【讨论】：

谢谢！好点在这里！不是我想问的。在询问之前，我实际上碰巧阅读了您的链接。不过，它并没有真正解决 Product 与 Product.Core 的问题。
要带回家的要点真的是“什么对你有用”。我已经在一个项目中看到了来自怪物项目的布局，导航到如此分离的项目是一场噩梦，以至于你必须在所有项目中引用如此多的东西，这基本上是毫无意义的。我个人遵循Project/Project.Core 范式，直到我绝对必须拆分它们。保持简单是您将拥有的最佳结构。
谢谢！所以您在 Project 和 Project.Core 中都有课程？我在想我要么在 Project 中拥有所有公共/业务逻辑（根本没有 Project.Core），要么在 Project.Core 中拥有所有公共/业务逻辑，而 Project 没有类。
所以Project 就是他们所说的“表示层”。它提供用户界面和类似的东西，用户与之交互。 Project.Core 提供了与程序交互的所有类。这将是业务逻辑、数据模型、服务等...然后您可以在以后将Project.Core 分离为Project.Core.Data、Project.Core.Services 等...这就是分离您的块。虽然，没有什么能阻止您从一开始就将其分离到 Core 项目中的这些命名空间中。事实上，我会建议它。