实体框架和业务层/逻辑

Question

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

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

想到了一些想法

选项1 - 制作ReceiptBo（收据业务对象） 继承Entity Receipt类和Icollection（ProductBo） ReceiptBo类负责添加Product，计算total和subtotal并调用Dal进行插入。 maby这个选项看起来有点矫枉过正。

选项2 - 使用部分类输出生成的Entity对象中的计算方法 并简单地使用BuisnessLayer来调用Dal。 这会使Buisnesslayer类在我看来过时，我不确定Entity类应该用于Business逻辑吗？

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

选项4 - 没有以上和我一无所知

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

我对业务层的含义也有点困惑。在一些例子中，它更像是一个Dal也用于计算，然后其他人说这没有完成。

一些帮助会很棒。 THX

ps：抱歉我的英文不好

Answer 1

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

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

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

Answer 2

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

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

此外，请不要忘记ViewModels应该反映视图，而不是Model，因此不是每个Model都会有ViewModel自己的<{1}} >