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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…