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

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

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

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

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

解决方案

实际上,我认为你从传统的分层架构中得到一些东西。通常,应用程序处理的数据模型将与业务层一起保存在业务层中。您的数据层将包含持久性框架的数据模型和与该框架交互的代码。我认为这可能是您的课程建议位置与您对课程的反应之间混淆的根源。

从这个角度来看,任何检索或带来的东西都必须位于您的数据层中 - 它正在访问持久存储中的数据。它检索的内容最终会转换为业务逻辑操作的业务层对象。事物是概念模型 - 如订单表 - 或业务操作属于业务层。我同意@Adron,或许同样对于(3)取决于它实际是什么的混淆。

更具体地说:

  1. 用户偏好是业务 对象,检索的东西 它们是一个数据层对象。
  2. 静态数据映射到企业 对象(表或视图或其他东西), 访问外部的东西 server是一个数据层对象。
  3. 用户权利是业务对象,检索它的是数据层对象。
  4. 订单表是业务对象
  5. 电子邮件是一项业务活动,因此邮寄人员的事情是业务对象
  6. [编辑]我对(简单)网络应用程序的通用3层体系结构

    DataAccessLayer

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

    BusinessLayer

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

    演示

    这些是我的网络表单 - 基本上是应用程序的UI。我确实在表单中包含了一些验证逻辑作为优化,尽管这些也在BL中得到验证。这还包括任何用户控件。

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

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

其他提示

您已指定 App.Data 应仅包含数据结构和接口,不包含实现代码,如果您想这样做,这很好,但是除了 App.BusinessLogic 程序集中之外,您无处可放置数据库访问代码。

也许您确实需要将 App.Data 重命名为 App.Model (或类似的名称),并拥有一个与数据库通信的新 App.DataAccess 程序集(可能实现存储库模式)。完成后,我会像这样分解事情:

  1. 应用程序数据访问
  2. 应用程序数据访问
  3. 应用程序数据访问
  4. 应用程序模型
  5. 应用程序业务逻辑

我可能会选择

  1. 数据
  2. 数据
  3. 数据,虽然我不完全确定班级在做什么
  4. 数据
  5. 商业逻辑
  1. -> 应用程序数据
  2. -> 应用程序数据
  3. -> App.BusinessLogic 或 App.Data - 不确定这到底意味着什么。
  4. -> 应用程序业务逻辑
  5. -> 应用程序业务逻辑
许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top