How should I separate entities methods?

Good people of SO,

Today I have some serious concerns on my business layer design. It is based on Entity POCO objects and I want to add logic to these entities BUT, there are 2 types of logic:

1. Pure C# logic
2. Persistence logic (LinqToEntities in my case)

My question is simple:

How should I separate these two kinds ?

First, I was thinking about 开发者_StackOverflow中文版adding these two as methods to the entities. And using partial classes to split them.

Second, I thought that I wouldn't want an overweight object with a LOT of methods. So maybe why not static classes or singleton with methods doing the LinqToEntities stuff, and leave the pure C# in entity methods. Then I would have several classes grouped by fonctionnality providing the logic, the entity is passed as argument to the classes methods.

It really bothers me, because the second solution seems cleaner but it looks like it breaks the object-oriented paradigm. On the other hand the first one seems like an anti-pattern.

What do you think ? Do you have a bright solution solving this paradox ?

Schizophrenic edit: in fact what I call persistence logic should go to the DAL and the pure c# logic in the BLL. POCO entities are produced by the DAL. I can then extend these entities in my BLL to add methods. In my DAL I should structure the logic as exposed in the second solution.

The logic that describes how an entity should be saved/loaded doesn't belong to the entity itself ; it's more likely to be the role of a persistence service, a data access object, etc.

I would let the object specific logic in the object -- we're here talking about the object behavior, then create a service that handles persistence concerns for this object type.