Hi all,
it's my first post here, and I'm curious whether someone can save my day (week, month...)
My problem is, that I'm doing the so called 95% boring part of my application, and I'm stuck with modelling the data-centric BO's.
Given the following use case:
Client can create a new Order. The order can be assigned an existing Customer.
The customer to whom the Order belongs to can be changed at any time.
Given an existing ERM with Order and Customer, with a foreginkey in Order to Customer allowing null values:
<Order> * ------- 0, 1 <Customer>
Given this question:
What's the Csla stereotypes to use?
I already tried:
Order = EditableRootObject
Customer = EditableRootObject
CustomerInfo = ReadOnlyChildObject.
Order.Customer as type CustomerInfo
Problem with this is.
Following the concept, whenever a new Order is created, it has to create it's Customer which is CustomerInfo in this case. However ReadOnlyChildObjects are intended to be read from existing data.
Thinking further it may not be possible to swap the Customer with another one. How should one get a reference to a CustomerInfo object, when these are loaded in context of a root object.
Throwing in a root object Customer for the Order doesn't seem to respect the BO guidelines as well.
Ok Csla is not ORM but stated here:
http://forums.lhotka.net/forums/t/10243.aspx
"The maintenance screens are generally data-centric, and so the screens, and their domain objects, and the data entity objects in the DAL all look like the table being edited."
Please someone shed some light on tihs.
Regards Martin
Hi,
Which is exactly why we typically "merge" 1:1 objects in terms of BusinessObjects (but not as entities in a database).
IE: Order to Customer is 1:1 - so I would have the necessary customer properties on the Order object.
The point of Business Objects is NOT reuse - it's Maintainability with lowest level of coupling and complexity.
Read Rocky's post here: http://forums.lhotka.net/forums/p/3465/17230.aspx#17257
BusinessObjects works best when they support the UI to make easy-to-bind objects and properties that encapsulate the behavior for that use case.
For more info read these posts: (and especially Rocky's posts in these threads):
http://www.lhotka.net/cslanet/faq/CslaObjectFaq.ashx
Thanks JonnyBee,
I already read the topics in detail.
Rocky states, these Data-Centric Objects are code generation candidates.
However the available Csla-Codegenerators/Templates don't seem to merge anything.
Binding I think becomes harder when we merge. Given an Order having a property of type Customer allows me to reuse the Control that is used to display a Customer. Further I have support for dynamically throwing in a Control at runtime based on the datatype of some property e.g. a ContentPresenter is beeing bound to, using DataTemplates.
Last but not least, there may be issues with the naming of properties when objects/entites are merged, not to mention the intellectual extra-effort one has to come up with.
Ah, forgot to mention, what if the Customer contains other complex types, let's say an address object, or maybe some kind of list?
Isn't there a concpet in CSLA to put a reference to something, what is actually a root object, into another rootobject? - Put the Customer inside the Order,
allowing for an easy swap to another Customer and so on?
Thanks again,
Martin
Rocky states, these Data-Centric Objects are code generation candidates.
However the available Csla-Codegenerators/Templates don't seem to merge anything.
A code generator doesn't impose any object design technique. You should design your objects according to UI needs. Forget object re-use, just focus on the use case (what's needed for the UI):
"What do I need to show on this form? What is the user requested to fill on this form?"
Sometimes a use case is quite similar to another (say a list and a detail form), as there are just some properties that are different. That's today requisites. Tomorrow there will be different requisites (say the form needs new fields). If you separate your use cases (list and detail form) and design objects for each of them, you only need to change the form and won't need to pay any attention to the list.
On the other hand, if you think of your list as a subset of the form data, the list takes longer to load and when you change the form, you might need to change something around the list.
Back to code generators, after designing your object (A property, B property, C child list, etc), you open your code generator, create the object and choose the object properties by click and point to database columns. When you do that, there are several cases:
Code generation should take care of all the above cases including the later, and should take care of all SQL handing for you.
Going back to the requisite change referred above, code generation really shines when you need to change your form:
Hope that helps.
Copyright (c) Marimer LLC