构建winforms C＃解决方案

Question

因此，我正在重新组织winforms C＃解决方案，以帮助解耦并使其更清洁，更有条理。该解决方案可跟踪小型业务订单等。

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

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

我有一些课程，我无法弄清楚他们属于哪里。请告诉我您对每个课程应该去哪个项目的想法，或者是否有另一个项目应该为此创建。

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

Answer 1

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

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

更具体地说：

1. 用户偏好是业务 对象，检索的东西 它们是一个数据层对象。
2. 静态数据映射到企业 对象（表或视图或其他东西）， 访问外部的东西 server是一个数据层对象。
3. 用户权利是业务对象，检索它的是数据层对象。
4. 订单表是业务对象
5. 电子邮件是一项业务活动，因此邮寄人员的事情是业务对象

[编辑]我对（简单）网络应用程序的通用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范例。

Answer 2

您已经指定App.Data应该只包含数据结构和接口，没有实现代码，如果您想这样做，这很好，但这使您无法放置数据库访问代码，除了App.BusinessLogic部件。

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

1. App.DataAccess
2. App.DataAccess
3. App.DataAccess
4. App.Model
5. App.BusinessLogic

Answer 3

我可能会选择

1. 数据
2. 数据
3. 数据，虽然我不完全确定班级在做什么
4. 数据
5. BusinessLogic

Answer 4

1. - ＆GT; App.Data
2. - ＆GT; App.Data
3. - ＆GT; App.BusinessLogic或App.Data - 不确定这意味着什么。
4. - ＆GT; App.BusinessLogic
5. - ＆GT; App.BusinessLogic