Time to revive and old thread I guess... over the past 3 years has anyone moved forward with the Dynamic Data concept in LLBL ?

The nice thing about the Dynamic Data approach is that all this data can be used for multiple purposes and is easily managed and maintained. I can use the Required attribute both in the validation as well as use it for the views. I can add a proparty to ignore a field (which is great as LLBL add many extra properties that are not data related). I can then use this same data for validation and for displaying the error messages, or for the Field Names to display.

This is of course for the cases of the simple field validations. Now using the class approach in LLLBL it is hard to manage the validations, not possible to surface these attributes for use in display capacity.

How do you in LLBL do: 1. Change the field Name to display as a title? 2. Define which are fields to display / not display on the form 3. Range Check & validations - this would be in the class validation structure. 4. Surface Error Messages - raising exceptions. 5. Define fields that are required (indicate this in the form)

Asside: Is this something in LLBL 3.0 ?

Dynamic Data seems to be a standard that is being used within many other systems within dot-net; so it would make life easy if we could leverage these systems where possible as well with LLBL.

Thoughts?

quentinjs wrote:

Time to revive and old thread I guess... over the past 3 years has anyone moved forward with the Dynamic Data concept in LLBL ?

I think it's also due to the fact dynamic data hasn't moved that much. In vs.net 2010, it will be updated to support inheritance for example, so we'll add that at some point.

The nice thing about the Dynamic Data approach is that all this data can be used for multiple purposes and is easily managed and maintained. I can use the Required attribute both in the validation as well as use it for the views. I can add a proparty to ignore a field (which is great as LLBL add many extra properties that are not data related). I can then use this same data for validation and for displaying the error messages, or for the Field Names to display.

This is of course for the cases of the simple field validations. Now using the class approach in LLLBL it is hard to manage the validations, not possible to surface these attributes for use in display capacity.

True, but let's first say that the attribute approach dynamic data uses is really not that great, as attributes are meta-data and in reality here, they're used as context bound elements of the data the class is contained. Not the same.

In dynamic data you can create buddy classes, which have just 1 purpose: supply attributes for properties and classes in generated code. This should help you get the attributes working in dynamic data. LLBLGen pro will never use these classes nor attribute based validation as it's a brittle way of doing things: our DI powered validation is more flexible and has better separation of concerns. But of course not usable inside dyn. data.

How do you in LLBL do: 1. Change the field Name to display as a title? 2. Define which are fields to display / not display on the form 3. Range Check & validations - this would be in the class validation structure. 4. Surface Error Messages - raising exceptions. 5. Define fields that are required (indicate this in the form)

If dynamic data supports it, you should be able to get these through attributes on buddy classes. Otherwise it's not supported (due to dynamic data)

Asside: Is this something in LLBL 3.0 ?

No. Dynamic data, as well as ado.net data services, will always be a separate piece of technology we will provide 'some' support for if possible, but it won't be part of llblgen pro natively.

What will be added in 3.0 is a system which allows you to add attributes to entities and fields etc. without much effort. This won't bring you validation inside llblgen pro with attributes, but it will allow you to define these attributes without the requirement of buddy classes.

Dynamic Data seems to be a standard that is being used within many other systems within dot-net; so it would make life easy if we could leverage these systems where possible as well with LLBL. Thoughts?

I think that's a bit over exaggerated. Dynamic data is nice, but IMHO it's not that widely used, also because of its limitations (no m:n relationships, no inheritance, no solution for 1:n relationships with many related entities: all entities are added to a single combo box!)

perhaps next version will be better, we'll see. We provide the code so dyn. data can read the entity definitions of our framework, what dyn. data does with them is out of our hands.