构造winforms C#解决方案

本文关键字：解决方案 winforms 构造 | 更新日期: 2023-09-27 17:47:49

因此，我正在重新组织一个winforms C#解决方案，以帮助解耦并使其更干净、更有组织。该解决方案跟踪小企业订单等。

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

应用程序视图-所有与GUI相关的代码
应用程序数据-只是数据结构和接口。没有其他实现代码
App.BusinessLogic-所有没有GUI的业务逻辑代码都引用

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

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

构造winforms C#解决方案

实际上，我认为您与传统的分层体系结构有些不同。通常情况下，应用程序所使用的数据模型将与操作它们的代码一起保存在业务层中。您的数据层将同时拥有持久性框架的数据模型和与该框架交互的代码。我认为这可能是你建议的上课地点和你根据评论做出的反应之间混淆的原因。

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

更具体地说：

  1. 用户首选项是业务对象，检索它们是一个数据层对象
  2. 静态数据映射到业务对象（表或视图或其他什么），访问外部的东西服务器是一个数据层对象
  3. 用户权限是一个业务对象，检索它的是数据层对象
  4. 订单表是一个业务对象
  5. 电子邮件是一种商业活动，所以给人发邮件就是一种商业对象

[编辑]我的（简单）web应用程序的通用三层架构

数据访问层

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

BusinessLayer

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

演示

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

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

注意：一旦ASP.NET MVC投入生产，我可能会转向MVC over 3-Tier。我用Ruby/Rails做了一些个人项目，我真的很喜欢web应用程序的MVC模式。

您已经指定了App.Data应该只包含数据结构和接口，而不包含实现代码，如果您想这样做，这很好，但这会让您无处放置数据库访问代码，除非在App.BusinessLogic程序集中。

也许您真的需要将App.Data重命名为App.Model（或类似的名称），并拥有一个与数据库对话的新App.DataAccess程序集（也许实现了Repository模式）。完成后，我会把事情分成这样：

  1. App.DataAccess
  2. App.DataAccess
  3. App.DataAccess
  4. 应用程序模型
  5. 应用程序业务逻辑

我可能会选择

  1. 数据
  2. 数据
  3. 数据，尽管我不完全确定这个类在做什么
  4. 数据
  5. BusinessLogic
  1. ->应用程序。数据
  2. ->应用程序。数据
  3. ->应用程序。BusinessLogic或应用程序。数据-不确定这到底意味着什么
  4. ->应用程序。BusinessLogic
  5. ->应用程序。BusinessLogic
相关文章：