ProjectTracker. Get it more complicated !!

Pavel posted on Wednesday, January 13, 2010

Hi everybody,

OOP is the most difficult part for me when it applied to CSLA object design.

I would like to make ProjectTracker more complicated to ask your advices how to implement it.

The additions are:

- some Resource for some (or all) Project can do different TypesofWork(design, testing, implementation and so on).
It can be different number of Works done for the Project or by Resources.

-each  TypesofWorks have some hours with some rates as properties.

I see TypeofWork as BB and TypesofWorkCollection as BLB.

This TypesofWorkCollection belongs to both Resource and to Project.

-Project done by different departments, so Department would be a Root.

I see 2 different scenarios here:

1.Root contains collection of Projects.
Project inside ProjectCollection contains  ResourceCollection.
Every Resource contains a collection TypesofWorkCollection.

2.Root contains collection of Resources.
Resource inside ResourceCollection contains  ProjectCollection.
Every Resource the same time contains a collection TypesofWorkCollection.

Probably, it could be more variations.

The scenario 2 questions:
But, how to implement it using CSLA objects?
Lazy Loading all collections as they would be created at a different point of time?
Create all collection and later just AddChild as Child created?
How to assign TypesofWorkCollection and ProjectCollection to Resource as I see here many-to-many relationship.

Thanks,

RockfordLhotka replied on Wednesday, January 13, 2010

Project <-> Resource is actually a M:M relationship, so ProjectTracker already demonstrates how to implement M:M, as well as 1:M.

I have yet to see a case where, in an OO design, there's a real argument for M:M like there is in the relational world. Since objects don't reflect just data, the nature of the relationships comes into play, and the relationships in a data-oriented M:M concept are (in my experience) never symmetric, and so the objects are never the same.

As I've said many times in the past, ProjectTracker is the demo app for the Expert Business Objects book. Therefore it has to meet certain requirements, not least of which is that I have to be able to describe the app (design and implementation) in just a couple chapters. That severely limits its size/complexity.

If I followed a different model, such as creating a more complex sample app that comes with the purchase of an ebook or video series focused on that app, that would break me out of the limitations of a paper book.

Or I could just create a large and complex sample app and give it away - but at the end of the day, like you, I need to generate income :)

Pavel replied on Wednesday, January 13, 2010

Thanks for a quick reply,

No, I do not want you to create ProjectTracker more complicated as I described it above.
I just wanted to see how some people deal with such a scenario, as I can see here lots of different approaches.
My problem is to figure out what is the right one regarding CSLA philosophy.

Pavel