Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
374 views
in Technique[技术] by (71.8m points)

c# - In separate data access & business logic layer, can I use Entity framework classes in business layer?

In separate data access & business logic layer, can I use Entity framework classes in business layer?

EDIT: I don't think I will need to swap out the data access layer from my business logic in the future (i.e. will be SQL Server), however I will for the UI layer. Therefore the question is more meant to be are there any major issues with using EF classes for me in the business layer? Seems like there would be less plumbing code.

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

Typically, the "best practice" approach would be something like this:

  • in your Data layer, you have EF entities that get loaded from and stored back to the database

  • in your Business layer, you have your own domain objects (just plain C# classes) that represent the data that your app needs to work on. Those can be more or less identical to a data layer entity, or they can contain several "atomic" entities to make up a business object, or they can be vastly different. To alleviate the need for a lot of left-hand-right-hand-assignment statements (to move property values back and forth between data layer entities and business layer objects), you should check out tools like AutoMapper that make it really easy to set up "mappings" between similar object types and allow you to easily assign those types back and forth

  • your UI layer(s) will then visualize and represent Business layer objects to the user for information and/or manipulation

The benefit is that your business layer domain model represents the actual business objects you're working with, and becomes more or less independent of how those are really stored in the data layer. Also, this avoids "glueing" your UI layer to a particular data access technology.

Of course - that's the recommended best practice for an enterprise-scale app, where you might need to swap out the data access layer etc. For a simpler app, you might skip those practices, knowing what you're doing, and that you're "locking" yourself into EF if you use EF entities all the way up through the business layer into the UI. If that's ok with you and your app scenario - there's no particular reason not to do it. EF entities are perfectly valid .NET object classes - they simply derive from a common base class (EntityObject instead of object) and they have a certain amount of "baggage" that comes along. But there's nothing stopping you from using those EF entities all throughout your app.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...