因此，我正在重新组织一个 winforms C# 解决方案，以帮助解耦并使其更清洁、更有条理。该解决方案跟踪小型企业订单等。.
到目前为止，我已将项目分解为
App.View - 所有与 GUI 相关的代码
App.Data - 只是数据结构和接口。没有其他实现代码
App.BusinessLogic - 所有没有 GUI 引用的业务逻辑代码
我有一些课程我不知道它们属于哪里。请让我知道您的想法每个班级应该去哪个项目，或者是否应该为此创建另一个项目。
实际上，我认为您与传统的分层架构有些不同。通常，您的应用程序所使用的数据模型将与操作它们的代码一起保存在业务层中。您的数据层将具有持久性框架的数据模型和与该框架交互的代码。我认为这可能是您的课程建议位置与您根据您的评论对它的反应之间产生混淆的根源。
从这个角度来看，任何检索或带来的东西都必然位于您的数据层中——它正在访问持久存储中的数据。它检索到的内容最终会转换为您的业务逻辑操作的业务层对象。事物是概念模型（如订单表）或属于业务层的业务操作。我同意@Adron 的观点，也许对于 (3) 的去向有同样的困惑，这取决于它实际上是什么。
进一步来说：
[编辑] 我的（简单）Web 应用程序的通用 3 层架构
数据访问层
这将包括我的 TableAdapters 和强类型 DataTables 和工厂，它们将我的 DataTables 行转换为 pre-LINQ 项目中的业务对象。使用 LINQ 这将包括我的 DataContext 和设计器生成的 LINQ 实体。
业务层
这将包括任何业务逻辑，包括验证和安全性。在 pre-LINQ 中，这些将是我的业务对象和实现应用程序逻辑的任何其他类。使用 LINQ，这些是我的 LINQ 实体的部分类实现，用于实现安全性和验证以及任何其他类来实现业务逻辑。
介绍
这些是我的网络表单——基本上是应用程序的用户界面。我确实在表单中包含了一些验证逻辑作为优化，尽管这些也在 BL 中得到验证。这也将包括任何用户控件。
注意：这是逻辑结构。项目结构通常反映了这一点，但在某些情况下，例如与 Web 服务的连接，可能会直接包含在 Web 项目中，即使在逻辑上组件确实在 BL/DAL 中。
注意：一旦 ASP.NET MVC 投入生产，我可能会通过 3 层迁移到 MVC。我在 Ruby/Rails 中完成了一些个人项目，我非常喜欢 Web 应用程序的 MVC 范例。
You have specified that App.Data should contain only data structures and interfaces, no implementation code, which is fine if you want to do that, but that leaves you with nowhere to put your database access code except in your App.BusinessLogic assembly.
Perhaps you really need to rename App.Data to App.Model (or something similar), and have a new App.DataAccess assembly that talks to the database (perhaps implementing a Repository pattern). Having done that, I would split things up like this:
我可能会去