C#: Pass BusinessObject to 'BusinessLayer' Constructor or its methods?

I'm charged with the support of a C# Winforms app which uses BusinessObjects (containing no logic, just properties) and a BusinessLayer with classes ('Helpers') that manipulate those entities.

The question: Should you pass in the BusinessObject to the Helpers constructor and then inside the constructor, instantiate the Helper's publicly accessible Entity variable OR Should you just pass the Entity to the methods that act on it?

Scenario 1: To the constructor

Car myCar = new Car();
CarHelper ch = new CarHelper(myCar);
ch.Wash(suds);
ch.Upgrade(upgradeKit);
ch.Save();

Scenario 开发者_开发百科2: To the methods that act on the Entity

Car myCar = new Car();
CarHelper ch = new CarHelper();
ch.Wash(myCar, suds);
ch.Upgrade(myCar, upgradeKit);
ch.Save(myCar);

Two major problems i have with Scenario 1: A) The next developer has to dig into the CarHelper class to realise that it has a public Car accessor property which it references within methods that need it. This further obfuscates the Helper class in that each method needs to check against a 'null' Car property before performing its duties... B) If there exists a bunch of other code in between operations, it can become unclear what ch.Wash() is actually doing...does it even act on a Car object at all...?

What does everyone think???

Is there any reason why you can't move the logic into the BusinessObject

Car myCar = new Car();
myCar.Wash(suds);
myCar.Upgrade(upgradeKit);
myCar.Save();

Do away with the helper class entirely. Makes more semantic sense to read, and there's no need to check for nulls.

Half as many classes to maintain as well

That's very true...wrapping up the logic in the BusinessObject to make it self-aware is best in my opinion too...i didn't consider that an option though because:

In 'the application' the BusinessObjects are in a namespace (....ApplicationServices) which is referenced by the DAO and so it can't actually call DAO methods (as it would cause a circular dependancy) - so it can't implement the functionality for

myCar.Wash(suds)
{
    this.CleanlinessRating = suds.CleaningAbilityRating;    
    // persist the level of Cleanliness to the DB
    CarDAO.Save(this);
}

It seems the premise behind the entire application is that the BusinessObjects do not implement any logic at all...they are just containers of information and do not have any behaviour.

Then you have BusinessLayer classes which act on the entities...

Then you have the DataLayer classes which persist the changes in the entites to the DB.

So apparently, making the Entities self aware and implement their own behaviour is a big 'no no' (in this application)... i'm sure that is the real problem here.

However, assuming i can't change that, what would you do?

1. Pass the entity to the methods that act on it? OR
2. Wrap the entity into the constructor of the Helper class?

What about making your CarHelper class extend Car

CarHelper helper = new Car();
helper.Wash(suds);
helper.Upgrade(upgradeKit);
helper.Save();

Best of both worlds