Entity object table-tennis

Today I've created an entity class that represents the data shown on the form. The purpose of this entity class is to act as a layer of separation between the form (View) and persistence mechanism.

It this point I think it is a good idea to clarify the responsibilities of each component:

Form (View):

• Manage all the controls on the form
• Present the data on the entity object
• Update the entity object with users edits

Entity (Model):

• Hold the data
• Manage default states (blank, keep data etc)
• Domain logic relating to this entity

Datamodule (Model):

• Persist data on entity object
• Populate entity object to contain data for currently selected record.

As you can see this is still violating the principle of single responsibility, but it is a big improvement on the starting position where all of this was on the form. The introduction of a controller class will further help, but that is for a later day.

I'm keen to move as much domain level logic out of the form, into the entity class as possible. This is for two reasons: the forms should be for presentation of the data only and the entity objcet should be more than just a data-holder. I'm going to focus more on this second reason.

Classes that do not have any methods, just data-properties, are child-like classes... they haven't grown-up yet. They are a good starting point, but if they stay as data-holders, there is something wrong with the overall design. Something is doing the work that this class should be doing.