我想知道为什么最常见的东西/基本逻辑不仅仅是产品。创建Product.Core并直接在Product中放置任何东西只是为了暗示什么类真的是关于什么？关于这个，有没有＆＃34;规则＆＃34; /最佳实践？
这是一个简单的问题，但我不确定我的写作是否有意义。
编辑：如果我在名称空间中划分了3件事：GUI，DataAccess和Business逻辑，并决定在3个名称空间中使用类。前两个是显而易见的：
Product.UI
Product.DataAccess
然而，业务逻辑可以放到
Product.Core
或
产品
现在我想知道更多＆＃34;标准＆＃34;：在Product或Product.Core中拥有业务逻辑。
如果将Business逻辑类放在Product中，则不会有Product.Core。
如果将Business逻辑类放在Product.Core中，那么Product将不包含任何类。
这两种方法都可以带来一些好处，我想知道人们的想法。
答案 0 :(得分：0)
这里有一些很好的讨论https://softwareengineering.stackexchange.com/questions/40394/how-do-you-organize-your-projects。
有一点是根据需要将解决方案分开以进行进一步扩展 - 但通常更容易根据需要进行重构。否则，分离项目有两个主要原因：
<强> 1。在关注范式分离之后
例如，在一个简单的Web项目中，我将有2个项目Project和Project.Core。这允许我将所有数据，逻辑和代码保存在一个项目中，同时将所有Web内容保存在另一个项目中。
<强> 2。在各个消费者/前端应用程序之间共享代码
例如，如果您打算使用Web应用程序和Windows服务，那么您将在服务和数据访问领域拥有通用代码。您可以将其移动到公共库，以便两个应用程序都可以利用相同的代码，而不是复制此代码。