Hi Everybody,
I'm confused regarding some of the examples I seen on ProjectTracker vs contents of the book, would appreciate if someone could enlighten me :
In the book, we see that a ReadOnlyList populates the ReadOnlyChild by invoking the static method ReadOnlyChild.GetReadOnlyChild(datareader), and GetReadOnlyChild in turn creates a new object which invokes the constructor, and the method Fetch(datareader).
But in the real implementation of ProjectList and ProjectInfo, what happen was the constructor was invoke instead, with the values retreived pass in as the parameters.
ProjectInfo info = new ProjectInfo(dr.GetGuid(0), dr.GetString(1));
Both may be doing the same thing - creating a child object and populate the values, but is there any difference? Would there be a poorer performance in the first implementation as compared to the second one, since we're passing around the datareader's reference? Which method do you guys normally used? I personally feel that the second implementation looks much cleaner and saves some code.
can someone advise on this? Thanks!
Hi,
I used the first implementation like ReadOnlyChild.GetReadOnlyChild(datareader) in my CLSA 1.x projects and I remember this from the examples of the old book. Now, where I change all my classes to the new CLSA 2.0 framework anyway, I also change the implementation to myReadonlyChild = new ReadOnlyChild(datareader). There should be no better or worse performance, but like you said, the code looks much cleaner.
Greetings,
Christian
I'd originally done this by calling the constructor directly. The technical reviewers for the book (at least one of them anyway ![Smile [:)]](/emoticons/emotion-1.gif)
) disliked this approach because the resulting code doesn't fit into the standard regions I set up in Chapter 6.
Ultimately I do think you should do the actual data loading in a Fetch() method in the Data Access region. And this should be called from your constructor. Whether the parent collection calls that constructor directly, or calls a factory method is (I think) relatively immaterial - it comes down to a matter of style and consistency.
On the whole I do think I favor the factory approach, even though it costs 3 more lines of code, because it provides consistency across all objects in terms of how they are created - but again, that's a matter of style as much as anything.
Copyright (c) Marimer LLC