Some clarification, please!

The validation classes generated by LLGLPro seem to validate individual entiry fields whenever a field value changes. However, this is a "chatty" approach to validation and is not efficient for distributed applications. I think that, in some cases, its better to validate the entire entity (object) one time just before the database is updated. Are you guys doing it this way? How? Do you think that the generated validation classes could be enhanced to include entiry-wide (not just individual field) validation?

Thanks! Jeff

JMichelson wrote:

The validation classes generated by LLGLPro seem to validate individual entiry fields whenever a field value changes. However, this is a "chatty" approach to validation and is not efficient for distributed applications.

It's not chatty, because the validation objects are inside the entity itself. This means that the entity uses an object that's inside itself for validation. These validations are for basic per field validations only, like "OrderDate has to be > today" etc. Not complex business logic validations. In a distributed application, you remote the entity object, and with that you remote the validator object as well (since it's inside the entity object), and thus will work nicely.

I think that, in some cases, its better to validate the entire entity (object) one time just before the database is updated. Are you guys doing it this way? How? Do you think that the generated validation classes could be enhanced to include entiry-wide (not just individual field) validation?

If you want to do entity-wide validation, you can do that using the 2-class scenario. With that, you get 2 classes per entity: "CustomerEntity" and "CustomerEntityBase". In CustomerEntity, you override UpdateEntity() and InsertEntity() and do the validation there. If the validation succeeds, you call base.UpdateEntity() or base.InsertEntity(), otherwise return false, throw an exception or whatever you want. Re-generating the code using two-class scenario's 'base only' or full/safe will not overwrite the 'CustomerEntity' class only the CustomerEntityBase class. Set the two-class scenario full/safe as your prefered scenario in the preferences so it gets preselected the next time you generate code.

Validating an entity in 1 go can be the solution if you want to perform some complex BL on the entity's data. If you just want to check if an ID is > 0, use a validator class implementation (which are never overwritten). You can also use a 'manager' approach which validates a passed in entity for correctness and returns true or false.

Next year enhancements are planned which will allow you to define concepts like 'Sales Order' which refers to objects like Customer, Employee, Order and OrderDetails. With that you also can define rules on them, which are complex validators in fact. For now, you have to add them manually as said above and move simple per-field validations into the validator classes and complex multiple-field (multiple entity perhaps) validations into the entity itself or in manager objects which in fact are business processes and execute rules based on input, in this case an entity or serie of entities.

Validation of string lengths for (n/var)char fields and variable/binary fields is done automatically, you don't need to set up validation for that.

Thanks, Otis.

Here's a follow-up question on this. When doing entity-wide validation, I like to return an ArraryList of errors back to the calling entity (typically the GUI). If (ArrayList.Count == 0) then there are no errors and the database can be updated. If (ArrayList.Count > 0) then there ARE errors and the database typically is not updated.

Do you agree that this would be best handled by a Manager class such as AccountManager? If this is how I plan to handle validation, should I still use the two-class generator?

Jeff

It's basicly a choice between: Do I use the 'entity' as the base for all my BL code, or do I use 'manager' classes with BL code which consume entities? The latter is more the approach like it is done for years in the COM world and also in older systems, it's a proven technology which produces self-documenting systems (i.e.: your 'manager' classes are in fact your BL processes which you defined in your system design). The former is more the approach of Fowler e.a. and is sometimes also called 'Domain model'. Because Domain model is not that adaptable for a serviced based architecture (SOA) (which is IMHO the way we write software today, yesterday and also tomorrow), and MS is going to adapt SOA as the way to produce software, I think it's a good choice to stay on the safe side and adapt the manager approach (because you can't go wrong on this).

The advantages of a class like 'AccountManager' is that it can't only verify account entities but it can also do this by consulting other entities and this makes sense since it is a class 'consuming' entities. If you place that kind of logic inside an entity object, it then also has to consult another entity, but why should an entity X know about the existence of entity Y if there is only a business logic relation between them, and what if a rule changes? You then have to alter one, two, maybe many entities to implement this change, while a manager class embeds the rules, so changes of business rules can be adapted more easier. An 'AccountManager' class also abstracts BL code from the GUI, the GUI will normally call 1 method to do something, which can affect multiple entities. This abstraction greatly enhances flexibility in the implementation of your total application (code reuse, multiple gui's etc.).

If you want to read more about this, there are a couple of discussions going on right now about this and related aspects in the newsgroup: microsoft.public.objectspaces (the group has more discussions about general topics than objectspaces hehe). Use the newsserver: msnews.microsoft.com (or use google groups )