实体框架和业务层/逻辑

Question

我试图建立一个产品/收据像应用程序的一个MVVM轻 - EF应用程序的体系结构的一些自学 。 我有一个产品和收据表/实体在多对多关系的Db/EF。 然后我有一个DAL，只需使用Linq来做简单的CRUD。

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

一对夫妇的想法浮现在脑海

选项1 -make一个ReceiptBo（回执业务对象） 至极继承实体收据类的ICollection（ProductBo） 的ReceiptBo类将负责添加产品，计算总计和小计，并调用Dal插入。 maby这个选项似乎有点矫枉过正。

选项2 通过使用部分类 和简单地使用BuisnessLayer调用达尔在生成的Entity对象计算方法-put。 这将使Buisnesslayer类在我看来过时，我不知道实体类应该用于业务逻辑吗？

选项3 -make的业务类，但不要打扰使用继承，只是将产品添加到实体的和做的计算存在，并调用达尔的插入。 这似乎很简单，但不是很优雅。

选项4 的-none以上和IM无能

现在即时通讯不使用WCF，但想法是，我想使这个应用程序松耦合，这样会很容易实现它，进一步扩展它。

也有点困惑什么业务层。在一些例子中，它更像是用于计算的Dal，后来有人说这没有完成。

有些帮助会很大。THX

PS：抱歉，我的英语不好

Answer 1

真的，我会去这里简单的选择一个共同的多层体系结构设计如下：

• 数据访问层（基本上，你的实体框架模型以及所有实体）
• 一个公开访问实体的方法的业务层（CRUD方法+运行某些逻辑的任何自定义方法）
• 通过WCF公开无状态方法的服务层（servi CE +使用MVVM图案数据合同）
• 表示层（你的情况）
  • 视图（XAML页）
  • 的ViewModels（C＃类）
  • 模型是由通过露出的实体这里表示业务层

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

Answer 2

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

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

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

的 ViewModel