Hi all,
I have these classes that I want them to inherit from several Csla classes.
In general, I know which classes to inherit from and which templates to use, but I'm not 100 percent sure.
I have a Customers root parent collection class that contains Customer child objects,
that in turn contain an Orders collection, containing Order objects (containing OrderDetails collection and OrderDetail objects).
I just don't want to make mistakes when implementing these classes. This is the core
of my application and it's very important to me, so I figured I'd ask the experts on this forum :)
Can you please help me choose the right tamplates and classes with these classes. I'm sure
that with other classes I will have a better idea of their implementation.
BTW, the root Customers collection class resembles IMHO to the Roles class the Mr. Lhotka implemented in his ProjectTracker example. Is this correct?
Thanks a lot,
Ben
So you have a single screen that shows all the customers in a grid, allowing the user to edit all of them. And when the user selects a row in the customer grid, on that same form they also get a grid allowing the user to edit all the orders for that customer?
That's pretty much the use case and/or UI experience you are supporting with the objects you describe.
With that model, if you have more than a handful of customers you'll find that performance is terrible. Also, it won't work well with more than one concurrent user, because any user would have loaded all the data and you'll have concurrency issues left and right.
My guess is that you really don't have one single screen, or one single use case. My guess is that you have an "edit customer" use case, a "edit order" use case, etc. Each of these use cases will almost certainly need different objects.
"Edit customer" for instance, will likely need:
"Create order" will likely need:
It is quite likely that the CustomerList/CustomerInfo objects from both use cases have the exact same responsibility and behaviors. If so, then they are the same object and you can achieve some reuse there.
Thanks for your reply Mr. Lhotka, I really appreciate it.
You were right regarding the use cases that you described. I really did plan to do it sort of like that.
I didn't consider the performance and concurrency issues. God, why does software development has to be so complicated :(
I'll take the direction that you have suggested. It looks much more reasonable. I don't know why, but I couldn't relate the text and the examples in the book to my needs. I guess I need some time to digest what's written in the book. I'll have to read the book again it seems.
Thanks for such a lovely book (I have the 2nd ed) and great community.
Ben
Copyright (c) Marimer LLC