Does anyone know of a control or a way of auto populating a .net form with controls for all the properties in a business object? I am looking for a fast easy way of generating the front end for a lot of business objects I have. Ideally it would take the business object and create a control based on the underlying datatype of the property anlong with a label for the property name. It should be dynamic in that it builds the controls at runtime. I have came across a control which is quite close called PropertyGrid by VisualHint www.visualhint.com however this only displays the data in grid form, albeit allowing you to control which .net control to use for the underlying data type.
We also use attributes and a control that at runtime renders the BO but it could just as easily be used to code gen a form instead.
These attributes are not just used for UI generation but rules enforcement as well. For instance Required, Min Length, Max Length, Coded values(NVL), Input mask(string patterns), are all specified in attributes that the UI utilizes and the BO also enforces.
We have tried to stay away from UI specific attributes such as position on form, but are considering doing that as well since they are just suggestions for the UI but can be ignored if the UI chooses. For instance if you use reflection to loop through your properties and display them a inputs on a form they should come out in source code order, but we have found that reflection actually caches the propertyinfo reference internally and if you access a propertyinfo of a property out of order before the UI generator gets to it, it will be placed at the top of the cache and come out first. So we are considering adding a TabOrder or DisplayOrder to the attribute to denote specifically which order it is to be rendered, and perhaps even more complex positioning attributes in the future(x,y).
Note this is a great boon to our development as we currently have a winform and RDL renderer for our BO and are working on a ASP.net renderer there by eleminating maintaining 3 UI's (or more) that all represent the BO in the same way but with different technologies.
Justin
Justin:
So we are considering adding a TabOrder or DisplayOrder to the attribute to denote specifically which order it is to be rendered, and perhaps even more complex positioning attributes in the future(x,y).
Justin
I agree that if we did implement some sort of x/y it would be logical and not tied to a specific UI technology.
We are trying to stay away from UI attributes but are starting to question why, beyond it being the "right" way to do things.
For our product it makes more sense to have have the BO define the UI as well since our UI is very regular and we are not large enough to have distinct developers for UI and BO and DB.
Justin
Danger Will Robinson! (OK, maybe you guys are too young for that).
In my opinion, the statement "For our product it makes more sense to have have the BO define the UI as well" is more likely an indication that you didn't need CSLA in the first place than it is a good way to design enterprise applications. To me that sounds the same as saying "in our company it makes more sense to have the accounting department running the mills on the shop floor."
Don't get me wrong - I built something like that before for a web site and it was very cool and functional, but it was a fairly simple application and definitely not n-tiered.
So, I think the basic premise of having a UI determined at runtime from metadata is sound and potentially useful, but that is UI metadata and not business layer metadata.
Believe me we are taking a cautious approach, we understand n-tier design and have a successful app written in the "right" way for the time which happend to be com+ windows DNA (remeber that?).
We have realized at least in our application design that most of what makes up the differences between one BO and another's BO UI is simply the data elements and business rules.
If you can infer the order in which the inputs on a form should be displayed from the source code order of the properties why not? Why write another object( a form object) and write glue code to bind the properties of one object to another when you could have just added a little decoration to your BO and the UI has all it needs?
Again these are just suggestions to the UI, should you need to make a different UI you can always code it by hand.
This works well for us because our UI is very regular between most entities, this may not work for others so well.
As I said we already have a functional winform and RDL renderer and they are scaling extremely well and productivity has been amazing with this design and the attributes add very little overhead to the BO.
As far as "in our company it makes more sense to have the accounting department running the mills on the shop floor.", well that is a little extreme but we are small enough that we don't have UI developers, BO developers, and DB developers or DBA's we just have developers and with this model a single developer can makes changes and test all the teirs much more quickly with fewer errors.
Justin
Copyright (c) Marimer LLC