We are using CSLA 4 and have a BusinessAddress object that references a Business object and an Address object along with properties of its own like Address Type. We need to bind to properties on the Business object and Address object from the same control.
Reading the properties works fine. For example binding to Business.Name reads the values as desired. However, when Csla.Data.DataMapper.Map() is called and it tries to set property values it fails when trying to find a property of name "Business.Name".
I could change the Map() method to look for dots (.) and if found load the business object to gain access to the property. If multiple levels were referenced this process could be repeated until the rightmost dot has been dealt with.
Since accessing child properties seems like a common scenario a better solution must already exist than resorting to modifing the framework.
How have others deal with this situation?
Thanks,
Jack and Sita
Hi Jack,
Usually the object graph is designed around the user scenario, not the data, so it has the shape required to perform the task. In most cases that means the shape of the object matches the need of the UI, because they are both designed around the same user scenario.
In the rare case that you can't design the object to fit the need of the user scenario (and I really think this should be rare!), you can use a viewmodel object between the UI and the business object to reshape the object. Basically create an object that does have the required shape (set of properties), and have that object delegate into the underlying business object(s).
I would imagine the most common usage of CSLA.NET has developers hand coding elements of the object graph. I would have preferred to do this at least until we have a significant degree of familiarity with CSLA.
I am not sure how we can create user interface centric CSLA business objects and keep generating code against our entity models and we really do not want to give up the productivity gains this has provided.
We have a complex business and data model relative to the size of our 'dynamic' project team. 300 plus core tables and 1 to 3 people filling all IT roles and regularly switching to other projects and back again. Given the scope of the project and the limited staff I wanted to automate our work wherever I could.
Historically, I have favored approaches that emphasize interpreting data at run time as opposed to generating code at design time. The former poses enjoyable coding challenges and you are not faced with the temptation of modifying generated code instead of the generator when under duress. However, between resistance from my peers regarding the complexity of interpreted techniques and discovering the existence of 'Visual Studio CSLA Extension for ADO.NET Entity Framework' on codeplex I opted for code generation. T4 templates remind me of working with classic ASP, and are not the most enjoyable thing to work with. However, we have taken 'Visual Studio CSLA Extension for ADO.NET Entity Framework' and modified it to meet our needs.
Visual Studio CSLA Extension for ADO.NET Entity Framework and our customizations to it include use of partial classes and methods so that the generated code can be tailored to some extent.
Using entity models with custom CSLA annotations we have generated CSLA business objects. We then have customization code files holding custom methods and implementations of partial functions as needed.
Given this I am tempted to created what could be called a Hierarchical Data Mapper that would be able to set child object properties by navigating the dotted notation used for referencing binding properties in our ASP.NET controls.
What concerns or warning do you have for me regarding approaching it this way?
Thanks,
Jack
I'd start by having you read the links in the first question on this FAQ page:
http://www.lhotka.net/cslanet/faq/CslaObjectFaq.ashx
Those may go a long way toward answering your questions on the way (at least I) view the topic.
Copyright (c) Marimer LLC