After talking with some folks about it, I did some refactoring to the structure.
Just to remind you my purpose:
- 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)
I don’t want to go all the way to my DB just to get the errors “ID column can’t be null” nor “Name field must be less or equal to 50 chars”.
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.
- Entities layer:
- In every set of the property(if the property is from string type, of course) -> validate the length of the property.
- 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.
- 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.).
- Delete action:
- Check that all the primary key columns are not null.
- Insert action:
Any thoughts ?
Like most of the times , I agree with you :)
yo, my man.
From my point of view I think that the only one who should check the Entity is the Entity itself.
This is why I think you should move all the ValidateXXX to the Entity.
I can’t see any reson to write this in the Dal, and I would like to hear what do you think about this.
The other stuff look nice.
btw, how do define the dirty? is it definition for each property ? what is the dirty for bool ?
please send me a simple example.
Hey,
1. The entity don’t need to know that ID property is a "key" (PK) in the data world. This cause me a little problem becuase I’m unable to determine if the entity is valid – as I mentioned in the post, the entity keys should be filled or not according to the data "action" (Insert,Update,Delete). One option is to move the IsValidForUpdate\Insert\Delete(or something like it) method to the entity and simply call it (from the BO, maybe) but this will "attach" the entity to the DAL – Nish Nish (no good in "Ali G" world) for me. The other option is to make the "nullable" & "keys" validations in the DAL, just before going to the DB. This seems like a good place because only the should DAL knows what are entity keys are or what its nullable fields are. I hope that the reason for seperating the validations are clearer now.
2. For each property, in their setter – I set a flag(boolean) which indicates that the property is dirty. This will help me later on in my Update method – update the field ONLY if it’s "dirty".
1) This reason was clear from the begining the only matter was wheter you gonna put this in the DAL or in the Entity.
In my opinion,
– For "nullable" and\or "length checks" there won’t be any problem to be validate by the Entity.
The Entity should know its types all the time, and there is no reason why it can’t tell me that i am inserting long string into the name property (when we create this data at the page).
But I agree that the "pk fields" should be checked in the DAL, because this one is for the DB only.
Do you agree or totaly not?
2) It sounds great but how does it work?
Is this flag is public or will be set by the setter only?
When you have a page with many fields (like registration form) and you have part of the fields changed and other not? how do you know what is the original ? and what is dirty ? (the whole object will be created from the fields of the form).
thanks.