c# - 构建 winforms C# 解决方案

Question

因此，我正在重组一个 winforms C# 解决方案，以帮助解耦并使其更清晰、更有条理。该解决方案跟踪小型企业订单等。 .

到目前为止，我已经将项目分解为

App.View - 所有 GUI 相关代码
App.Data - 只是数据结构和接口(interface)。无其他实现代码
App.BusinessLogic - 所有没有 GUI 引用的业务逻辑代码

我有一些类，我不知道它们属于哪里。请告诉我您的想法，每个类(class)应该去哪个项目，或者是否应该为此创建另一个项目。

1. 从数据库中检索用户首选项的类
2. 从我们的静态数据服务器检索静态数据并返回数据结果集的类。
3. 降低用户权限的类
4. 存储订单哈希表的模型类
5. 通过电子邮件发送有关用户操作的消息的类

Answer 1

实际上，我认为您与传统的分层架构有些不同。通常，您的应用程序所处理的数据模型将与操作它们的代码一起保存在业务层中。您的数据层将同时具有持久性框架的数据模型和与该框架交互的代码。我认为这可能是您建议的类(class)位置与您根据您的评论对它的 react 之间混淆的根源。

从这个角度来看，任何检索或带来的东西都必须位于您的数据层中——它正在访问持久存储中的数据。它检索的内容最终会转换为您的业务逻辑所操作的业务层对象。事物是概念模型——如订单表——或属于业务层的业务操作。我同意@Adron 的观点，也许，对于 (3) 的去向取决于它的实际情况，可能会有同样的困惑。

更具体地说:

1. 用户偏好很重要对象，检索的东西它们是一个数据层对象。
2. 静态数据映射到业务对象(表或 View 或其他东西)，访问外部的东西服务器是一个数据层对象。
3. 用户权限是一个业务对象，获取它的是数据层对象。
4. 订单表是一个业务对象
5. 发邮件是一种商业事件，所以给人们发邮件的东西就是一个商业对象

[编辑] 我的(简单)网络应用的通用 3 层架构

数据访问层

这将包括我的 TableAdapter 和强类型的 DataTables 和工厂，它们将我的 DataTables 的行转换为 pre-LINQ 项目中的业务对象。使用 LINQ 这将包括我的 DataContext 和设计器生成的 LINQ 实体。

业务层

这将包括任何业务逻辑，包括验证和安全性。在 LINQ 之前，这些将是我的业务对象和实现应用程序逻辑的任何其他类。使用 LINQ，这些是我的 LINQ 实体的部分类实现，用于实现安全性和验证以及用于实现业务逻辑的任何其他类。

介绍

这些是我的网络表单——基本上是应用程序的用户界面。我确实在表单中包含了一些验证逻辑作为优化，尽管这些也在 BL 中进行了验证。这还将包括任何用户控件。

注意:这是逻辑结构。项目结构通常反射(reflect)了这一点，但也有一些情况，例如与 Web 服务的连接，可能直接包含在 Web 项目中，即使逻辑上组件确实在 BL/DAL 中也是如此。

注意:一旦 ASP.NET MVC 投入生产，我可能会转向 3 层以上的 MVC。我在 Ruby/Rails 中完成了一些个人项目，我非常喜欢 Web 应用程序的 MVC 范例。