+2  A: 

You can architect your solution using (Plain Old C# Objects) POCO's and Managers.

That way you separate the business logic from the value objects.

To make it "look pretty", you can mark your methods with the (this) modifier on the parameters so you can then use those methods as extension methods.

An example could make this pretty clear:

Location Value Object:

public class Location
{
    public string City { get; set; }
    public string State { get; set; }
}

Location Manager:

public static class LocationManager
{
    public static bool IsWashington(this Location location)
    {
        return location.State == "WA";
    }
}

Now, the extension methods will show up differently than the standard properties/methods on the object.

The "IsWashington" method can be called 2 ways

Location location = new Location { State = "WA" };
LocationManager.IsWashington(location);

OR

Location location = new Location { State = "WA" };
location.IsWashington();

Now you have separation of your business logic and value objects, yet you still can have "pretty" method calls.

If you feel your fellow devs (or you :) ) will abuse the extension method part, then just don't use it.

CubanX
+1  A: 

I also use entity framework and tried first to extend the classed but I soon found that was not a good solution so I ended up making new classes (in a new class library) which I prefixed with a B. I did not extend the entity classes.

If I have a class named NewsPost the business class is named BNewsPost and all business logic connected to that class is collected here. For join the returning elements of used to place the logic.

Not a very exiting solution but it did the trick.

regards