mapping - Necessity to decouple business objects from entity framework (POCOs) objects? -

in our application upgrading existing dal ef 4.0 ef 5.0.
currently generic repository pattern implemented , using poco objects business entities.
these objects decorated wcf attributes, since passed in web services interfaces , extended partial classes in order add further business , validation methods. each poco entity inherits base class "businessentity" , interface "ibusinessentity" in order use generics repository methods easily.

we planning decouple business entities pocos objects in order make latter plain classes properties , no logic.

however after reading topic, seems current state of art adopt code first approach , persist domain entities directly (even if of course not possible generalize cases).
related answer 1, related answer 2.

in our case, make sense keep poco objects business logic in them , apply changes related ef 5.0 (dbcontext)? or rather should introduce mapping layer inside repository? in way application work on business entities , repository layer hide pocos object outside. downside introduction of complexity, expecially when dealing generic repository.

thanks in advance.

i want share experience regarding question, although came here finding solution another, related, problem.

most of people , articles read saying use ef pocos business objects... me, looks ef drives tendency because if want decouple them, make development more complex.

you said, have ef pocos in system. well, want see opposite angle: have project where, in beginning, dal used our own basic 'database handler' written pure ado.net, , our own business classes; try support entity framework well, in addition (so load either old db handler or ef... maybe later switch ef). since want keep database is, go database-first approach; couldn't find way make easier connection between our existing business objects , pocos (we use simple 'projection' conversion @ moment).

so, in bl, following preudo-code insert 1 bobject1 has list<bobject2> (1:n relation) looks this:

 this.unitofwork.executetransaction(() =>  {     bobject1_repository.insertbobject1(bobject1);      foreach (var bobject2 in bobject1.listbobject2)        bobject2_repository.insertbobject2(bobject2);  }); 

all our old 'db handler'; reuse same transaction , implicitly, same connection... ef now, gets tricky. in order insert bobject2, first may want have maybe auto-gen. uid bobject1 (already known after first insert)... not available in ef, unless call savechanges prematurely after first insert. more 1 'savechanges' calls involved, have think happens these transactions. distributed transactions (dtc) 1 hiccup... case our project when want support oracle databases... , stuck here.

i hope see things angle well...

aside note:

would nice hear opinions of experienced in ef , oracle regarding usage of transactions in bl; me my question well.