实体框架和业务层/逻辑 [英] Entity framework and Business Layer / logic
问题描述
尝试构建产品/收据（如应用程序）。
我有一个Db / EF与一个产品和收据表/实体在许多到许多关系。
然后我有一个DAL，只需使用Linq来做简单的CRUD。
问题是在哪里和如何把我的业务逻辑在这个应用程序。 p>
想到了几个想法
选项1
-make ReceiptBo（收据业务对象）
继承Entity Receipt类和Icollection（ProductBo）
ReceiptBo类将负责添加产品，计算总计和小计，并调用Dal进行插入。
maby这个选项似乎有点过分。
选项2
输入生成的实体对象中的计算方法通过使用部分类
和简单地使用BuisnessLayer来调用Dal。
这将使我的意见中的Buisnesslayer Classes过时，我不知道Entity类是否应该用于Business逻辑？
选项3
- 制定业务类，但不要使用继承，只需向Entity添加产品并在其中进行计算，并调用Dal进行插入。
看起来很简单但不是很优雅。
选项4
- 无上述和无知的
现在我不使用WCF，但想法是我想让这个应用程序松动耦合，这样很容易实现它，并进一步扩展它。
还有一点对商业层是什么感到困惑。在一些例子中，它更像是一个Dal，它也是计算的，然后其他人说这个没有做。
一些帮助将是伟大的。 thx
ps：对不起我的坏英语
通常我将我的业务逻辑保留在我的 ViewModels 中，而不是我的模型，我将EF对象视为模型。他们最多会有一些基本的数据验证，例如验证长度或必填字段。
例如，一个 EditRecieptViewModel 将验证业务规则，例如验证值在特定范围内，或验证用户是否可以访问对象，或者在值更改时执行某些自定义计算。
另外，不要忘记， ViewModels 应该反映View，而不是模型，所以不是每个模型将有一个 ViewModel 自己的
im doing some self-study on architecture of a MVVM-light - EF Application im trying to build a product/Receipt like app. I have a Db/EF with a Product and Receipt Table/Entity in a many to many relation. then i have a DAL wich simply uses Linq to do simple CRUD.
the question is where and how to put my business logic in this app.
a couple of ideas came to mind
option 1 -make a ReceiptBo (Receipt business object) wich inherit the Entity Receipt class and Icollection(ProductBo) the ReceiptBo class would be responsible for adding Product,calculating total and subtotal and calling the Dal for inserting. maby this option seemed a little overkill.
option 2 -put the calculating methods in the generated Entity objects by using partial classes and simply using the BuisnessLayer to call the Dal. this would make the Buisnesslayer Classes obsolete in my opinion and im not sure that Entity classes should be used for Business logic at all ?
option 3 -make the Business Classes but dont bother using inheritance, just add products to the Entity's and do the calculations there and call the Dal for insert. wich seems simple but not very elegant.
option 4 -none of the above and im clueless
right now im not using WCF but the idea is that i want to make this app loosly coupled so that it would be easy to implement it and further extend it.
also im a little confused about what an Business layer is. in some examples it is more used like a Dal that also does the computing, then others say this is not done.
some help would be great. thx
ps: sorry for my bad english
Usually I keep my business logic in my ViewModels, not my Models, and I view EF objects as Models. At most, they'll have some basic data validation, such as verifying length or required fields.
For example, an EditRecieptViewModel would validate business rules such as verifying values are in a specific range, or verifying that users have access to edit the object, or performing some custom calculations when a value changes.
Also, don't forget that ViewModels should reflect the View, not a Model, so not every Model will have a ViewModel of its own
这篇关于实体框架和业务层/逻辑的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
