Is it bad practice to use the code-gen'ed objects from Entity Framework as business objects? Or is it better to write a secondary wrapper around Entity Framework objects that I would then pass between layers?
For example, write my own POCO Person that accepts one of my code-gen'ed Entity Framework object EFPerson to initialize the POCO Person object?
I don't see why it would be bad practice. It might be awkward according to how you intend to use your EF objects.
I have partial classes to implement BIZ logic in the EF objects, using an Interface to provide a level of abstraction.
eg.
public partial class Client : IClient
{
void DoSomething();
}
// then an EF generated object ...
public partial class Client
{
// ...
}
My only problem I have had is serializing the objects. In my case, serializing into JSON using WCF. It isn't possible without creating an intermediate DTO either as a discrete class/object or as an anonymous type.
If you're interested in serialisation, have a look at another question of mine here: http://stackoverflow.com/questions/657939/serialize-entity-framework-objects-into-json
While some people tend to wrap the Entity Framework classes into their business objects, I would usually suggest not to do that.
I understand that this improves the separation of business logic and data access, but I think that this is usually not worth the overhead of duplicating all entity types.
What is the purpose of an OR mapper? It is to persist business objects without the need of a complex data access layer mapping the objects to the database by hand. If you wrap the Entity Framework classes, you will only use half of the gained convenience.
And finally the coupling between data access and business logic is not that tight with partial classes. Not long ago I changed a project involving about 30 entities from Entity Framework to LINQ to SQL in only a few hours without major problems.