实体框架和业务层/逻辑

Question

我正在对 MVVM-light 的架构进行一些自学 - EF 应用程序 我正在尝试构建一个产品/收据之类的应用程序。 我有一个 Db/EF 与产品和收据表/实体的多对多关系。 然后我有一个 DAL，它只是使用 Linq 来做简单的 CRUD。

问题是我的业务逻辑在哪里以及如何放在这个应用程序中。

想到了几个想法

选项 1 - 制作 ReceiptBo（收据业务对象） 它继承了实体收据类和 Icollection(ProductBo) ReceiptBo 类将负责添加 Product，计算总计和小计，并调用 Dal 进行插入。 可能这个选项似乎有点矫枉过正。

选项 2 - 使用部分类将计算方法放入生成的Entity对象中 并简单地使用 BuisnessLayer 调用 Dal。 在我看来，这会使 Buisnesslayer 类过时，我不确定实体类是否应该用于业务逻辑？

选项 3 -制作业务类但不打扰使用继承，只需将产品添加到实体并在那里进行计算并调用 Dal 进行插入。 这看起来很简单，但不是很优雅。

选项 4 -以上都不是，我一无所知

现在我没有使用 WCF，但我的想法是我想让这个应用程序松散耦合，以便它易于实现并进一步扩展它。

我也对业务层是什么感到有些困惑。在某些示例中，它更像是一个 Dal，它也进行计算，然后其他人说这还没有完成。

一些帮助会很棒。谢谢

ps：对不起我的英语不好

Answer 1

真的，我这里比较简单，选择一个通用的多层架构，设计如下：

• 数据访问层（基本上是您的实体框架模型以及您的所有实体）
• 一个业务层，公开访问实体的方法（CRUD 方法 + 运行某些逻辑的任何自定义方法）
• 通过 WCF（服务+数据契约）公开无状态方法的服务层
• 表示层（在您的情况下使用 MVVM 模式）
  • 视图（XAML 页面）
  • ViewModel（C# 类）
  • 模型在这里由服务层通过 WCF 公开的实体表示

我不会直接在实体中添加任何方法。所有方法都在业务层定义，并由服务层公开。

Answer 2

通常我将业务逻辑保存在我的ViewModels 中，而不是我的Models 中，并且我将EF 对象视为Models。他们最多会进行一些基本的数据验证，例如验证长度或必填字段。

例如，EditRecieptViewModel 将验证业务规则，例如验证值是否在特定范围内，或验证用户是否有权编辑对象，或在值更改时执行一些自定义计算。

另外，不要忘记 ViewModels 应该反映视图，而不是 Model，所以不是每个 Model 都会有自己的 ViewModel