After talking with some folks about it, I did some refactoring to the structure.

Just to remind you my purpose:

1. I want to validate the data before sending it to the DB(performance stuff), or at least at some level:

• For "string" fields - check for their length (by DB definition).
• For not nullable fields - check that they aren't null, depending on the required action (Insert, Update, Delete)

The actions I took:

In the ideal world, the entity would know how to validate it self, from A to Z, but the problem is that the validations change according to the required action(Insert, Delete, Update) and I don't want to couple my entity with my DAL.
I decided to split the "validation" checking in two - some of it in my Entities layer and the other some, in my Data-Access layer.

1. Entities layer:
   • In every set of the property(if the property is from string type, of course) -> validate the length of the property.
2. Data-Access layer:
   • Insert action:
     • Check that all the not nullable fields aren't nullable, unless the column is an Identity(auto-increment) field.
   • Update action:
     • If the field has to be updated (its status is "dirty", meaning, the programmer wants to update it) -> check for his "null condition" (all rights for this phrase are reserved for me, Oren Ellenbogen Inc.).
     • Check that all the primary key columns are not null.
   • Delete action:
     • Check that all the primary key columns are not null.