I've paid for the ebooks, I have all the samples, nothing is equal to a good working full featured sample project that illustrates *all* the business object stereotypes.
I'm still floundering with aspects of CSLA 4.x that would be instantly understandable with a simple good working sample like project tracker.
Please port the project tracker sample to 4.x csla.
You've made this request in at least a couple previous threads. I have said that I plan to do this as part of the final three ebooks in the series. Is it really necessary to repeat this discussion yet again?
Whoa! Hold up a second there Rocky, I don't mean to annoy anyone and I apologize if I was but I think you're thinking of someone else.
I posted a question a while ago about having trouble getting project tracker working.
JonnyBee related to my and other people's surprise that of course it was not working and should not be used as that was supposedly common knowledge.
You posted a lengthy message about how you really didn't want to support it and that it was difficult to do and would result in at least 4 different sets of code and you'd prefer smaller targetted samples in future but then at the bottom of that message you stated that you might look at it again in March as part of another ebook you'd be working on.
At no point have I understood it to be a given that there would *ever* be a Project Tracker sample or even any fully working sample with every object stereotype in it.
Hence my request and why I didn't think I was repeating anything at all.
Sorry - it must not have been you. The topic has come up numerous times over the past couple months.
It is true - after 15 or so years of maintaining that same app, I find it very uninspiring.
At the same time, it is a decent app, that demonstrates many of the stereotypes (though not all). The sample app for the Data Access ebook demonstrates them all - but without a UI - only unit tests.
I've said more than once though, that boring or not, I intend on using ProjectTracker for the WPF/Silverlight, ASP.NET MVC, and WP7 ebooks. That requires that I rewrite the app with those types of interface - and while I'm at it, I'm rewriting the data access model to match the encapsulated invoke model used in the Data Access ebook. Probably the DTO variant, though I'm still considering using the data reader variant because it is more efficient.
I will be dropping the Windows Forms, Web Forms, and XML service interfaces though - at least for now. They aren't part of the ebook series, so they aren't a focus in the short term.
If/when I write individual ebooks for those UI technologies (and I'll almost certainly do a service-based ebook at some point), I'll add those interface types back into the solution.
(I must be honest and say that I probably won't write a Windows Forms ebook - since that technology hasn't changed in any meaningful way for 6+ years, it is hard to imagine there's a lot of value in such an ebook? The same is true for Web Forms - unless the next version of .NET actually enhances Web Forms in some way, it too hasn't changed for 6+ years...)
I've said more than once though, that boring or not, I intend on using ProjectTracker for the WPF/Silverlight, ASP.NET MVC, and WP7 ebooks. That requires that I rewrite the app with those types of interface - and while I'm at it, I'm rewriting the data access model to match the encapsulated invoke model used in the Data Access ebook. Probably the DTO variant, though I'm still considering using the data reader variant because it is more efficient.
People tend to reproduce the sample applications. Beginners in special, start by reproducing them. You chose to port PTracker to encapsulated invoke as this model is the one you recommend (Using Csla 4: 01-Overview, p. 104). I guess that's the model that will be most followed even by people that didn't read the ebook. If the PTracker sample uses DTO, most people will use DTO. As you say the data reader variant is more efficient and provides optimal performance (Using Csla 4: 01-Overview, p. 75). As a conclusion, I'd say it's best to use a data reader variant.
Tiago.
Perhaps I'm wrong, but according Lhotka views it is true that the data reader approach has better performance. But as for me, this way is only valid for small applications, with not to many fields to be readed/saved. I think it's a more useful sample (in a future Project Tracker sample) the Encapsulated Invocation Model with DTO (according the data ebook).
If I'm wrong, I apologize for my poor understanding.
Raúl
I want to be very clear here.
The code samples that come with the Using CSLA 4: Data Access ebook show how to implement every stereotype with three data access models:
I chose not to create sample code for:
Partially because these are (imo) not the best approaches. And partially because if you know the first three, you should be able to figure out how to do the other three - they are just variations on the same themes.
So when we talk about ProjectTracker, I need to pick one of the three preferred models. I thought about selecting the model by rolling a d6/2 (yes, I'm a gamer geek), but I personally prefer the encapsulated invoke model as a general rule.
So that means it is either data reader or DTO. That's a toss-up. I'll be implementing mock and EF DAL implementations (and maybe a raw ADO.NET implementation, but probably not initially). At this point I really could flip a coin - they are both extremely similar in implementation, but they aren't interchangeable.
The data reader approach is more efficient, but doesn't lend itself well to a DAL that calls services instead of a database. But I don't plan to show a DAL that calls services - at least not in ProjectTracker.
The DTO approach is more elegant and flexible, but is less efficient.
If people want to copy some code for their app - they should read the Data Access book, make an intelligent decision based on the information in that book, and then copy one of the three sample apps from the book. That's the smart thing to do.
On the other hand, if people want to copy the somewhat arbitrary choice I make for ProjectTracker, without educating themselves on the other options - I guess that's their "choice" :)
Rocky, is there any news on a sample project for the Encapsulated Invoke Data reader model?
That model makes most sense to me. As I'm only getting my feet wet in CSLA 4, the process of re-engineering the PTracker project from DTO to Datareader will, I'm sure prove frustrating.
I don't *See* evidence of it in the samples....
Thanks,
Graham
This is one of the samples that comes with the Data Access book.
I have the book - and have downloaded the samples. The only ProjectTracker solution I see is:
\CSLA\05-WpfSl-111028\05-WpfSl-111028\NET\cs\ProjectTracker\ProjectTracker.sln
Which if I am correct is the DTO model and not the DataReader model. Should I be looking elsewhere?
Thanks,
Graham
There are a set of samples for the data access book that demonstrate the different data access techniques I recommend.
It is unrealistic for me to maintain something like projecttracker with several different DAL models, so I created more targeted samples for the data access book.
Yeah, the ActionExtenderSample doesn't really help.
My re-igniting this thread was mainly due to your comment Rocky, that you were probably going to produce a ProjectTracker sample using the Encapsulated Invoke with datareader model.
Previous posters made valida points about using the sample application to form the basis for ones own development - which I did successfully in CSLA2.
As Enscapsulated invoke is one of your suggested models, and DTO is an overhead that - if I understand correctly should only really be necessary if we aren't directly using ADO/Net, then I *thought* that the ProjectTracker sample would have been written using that model.
Another nice thing about using the ProjectTracker example as a base, is that it incorporates authentication, which obviously the samples in the DAta access code don't.
My dilemma/issue is caused by a number of factors;
I have to try and piece the samples together from various projects like ProjectTracker, EncapsulatedInvole, etc and TRY to come up with a basis that incorporates the required model AND using authentication. As I code in VB.Net, this is exponentially made harder as I have to somehow, deconstruct/construct or translate the C# code before creating the new classes. Subsequent errors, reference issues are then a headache, because I'm second-gessing whether the code is translated correctly or whether I have issues with references to libraries, etc.
If no ProjectTracker for this model is provided, would it be a chore to put together a structure of the Libraries/classes that should comprise such a project?
E.g.
ProjectTracker.Dal
DalFactory.cs
IDalManager.cs
IResourceDal.cs
...
ProjectTracker.DalMock
Dalmanager.cs
ResourceDal.cs
ProjectTracker.Library
ResourceEdit.cs
etc...
The DTO objects in the sample project are definitely muddying the waters for me...
Thanks,
Graham
There is a project that shows the structure and full implementation in the samples for the 'Using CSLA 4: Data Access' book.
The ActionExtenderSample also uses DataReader for data access.
ProjectTracker is also included in the CSLA Samples download here:
http://www.lhotka.net/cslanet/Download.aspx
Sorry, but I really don't want be seem dense, but I have downloaded the 4.2.2 Samples and I see no version of ProjectTracker that uses the datareader model for EncapInv - which is what is inferred at the start of this thread.
Jonny, where is the ActionExtenderSample exactly?
Samples\NET\cs\ActionExtenderSample in the Samples download.
ProjectTracker is updated recently and is in the latest Csla 4.3.2 Samples download.
Copyright (c) Marimer LLC