实体框架和业务层/逻辑

Question

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

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

我想到了几个想法

选项 1 -制作一个ReceiptBo（收据业务对象） 继承Entity Receipt类和Icollection(ProductBo) ReceiptBo 类负责添加 Product、计算总计和小计并调用 Dal 进行插入。 也许这个选择似乎有点矫枉过正。

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

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

选项 4 -以上都不是，我

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

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

一些帮助会很好。 thx

ps：抱歉我的英语不好

Answer 1

实际上，我会在这里简单地选择一个通用的多层架构，设计如下：

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

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

Answer 2

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

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

另外，不要忘记 ViewModels 应该反映视图，而不是 Model，因此并非每个 Model 都会有 ViewModel< /code> 自己的