newbie: where do I go from here?

dbsaxman posted on Monday, March 03, 2008

I got the PTracker app working to my satisfaction; thanks Joe Fallon et al for your help.  Now I'm trying to figure out how to get a real application working, using the framework.  I see the stuff about templates on CodePlex etc, and it seems to make sense that one would want to use templates to create a new app based on the framework, but that in itself seems like a whole complex world of information that will require lots of research and understanding.  Basically all I'd like to do is get a simple application working, say, to add, edit and delete records from a single table, and list the records in the table, based on the PTWeb application design.  Without having to learn all the stuff about templates etc, can anybody recommend a simple approach to just getting started?  My general fumbling makes me think I might try various approaches, such as:

1. hacking the PTWeb app such that I sort of copy and paste code from ProjectList etc, and just model some design after the existing code.  Even though I know this is probably bad practice, it might be a way of just getting started, by doing it wrong a few times, until I get the hang of it so I can eventually refactor my code and learn how to do it right by trial-and-error.

2. start from absolute scratch and try to just follow the steps as shown in the book, and just start out with an empty solution that references the CSLA20cs, where the directories are set up in a similar hierarchy to the PTracker app, so I can try to emulate that design, but where I'm just coding a page from scratch with all its attendant .cs files, code behind files etc, so that it references Some.Library like the PTracker app...

3. or, some approach that I don't understand that represents best practices, but which I cannot seem to glean from the book, additional handbook or website.

I don't have CodeSmith or any code generating tools, and I'd kind of like to learn how to code this by hand before going down the road of learning to automate it.  Option # 2 above seems like the way I might learn to do it right, without having to copy and paste stuff.

Any help appreciated, thanks, -Dave

JoeFallon1 replied on Monday, March 03, 2008

I vote for #2.

Keep Project Tracker open so you can refer to it, but try to create a small app from scratch to learn the framework. It is well worth the effort.

I agree that trying to learn "everything" at once is overwhelming - I tried it 4 years ago and it almost killed me. <g>

Tips:

1. Create a class that inherits from each CSLA and store that in a special folder. This is known as the Intermediate Base Class. e.g. CSLA has BusinessBase so you will create MyBusinessBase which inherits BusinessBase. (See older threads for the exact syntax - it can be convoluted with Generics.)

Do this even if you have no code to add. (Later on you *will* need to add code and you will thank your lucky stars you created this intermeidate class because the new code will work for all of your BOs.)

2. When you write the code for your Root BO use 2 classes. The first class will always inherit from one of the intermediate base classes above. So if you have an Account class the first will will be called AcctBase and will inherit from MyBusinessBase. The 2nd will be called Account and will Inherit from AccountBase. (Alternatively you could use Partial classes to accomplish this but they have their own set of quirks which I am not overly familiar with.)

Put as much code as you can in AcctBase. This is where a Code Generator will add all of its output. The idea is that you should be able to re-generate the Base level class and not lose any hand coded changes. So by building both classes by hand, you will learn how difficult it is to set up all the regions and other standard areas for a BO. Then you will get Codesmith and have it do all that work for you in 2 seconds.

In the Account class you should basically have no code. As a learning exercise you can add a field and Property to the Account class which returns the full name of the user who entered the Account record. This means that your code will need to access a different table (a Users table) and take the ID from the Account field and use it to get the full name. This is where you will learn that Overriding DataPortal_Fetch and calling MyBase.DataPortalFetch is very useful. You hand coded Bo only has a couplf of lines of code to return the Base set of data for the Account and then you can write 1-2 more lines to get the full name of the user and populate your "borrowed field".

I split out the DP_Fetch into a few subroutines like FetchData, FetchChildren, PostFetch. Then I only need to override a speciifc sub instead of the whole DP.

That should get you started.

Good luck.

Joe

 

 

dbsaxman replied on Tuesday, March 04, 2008

Got it, thank you again Joe.  I will proceed along your recommended path, sounds quite sensible and will teach me best practices.

Perhaps someday you can write "CSLA for Dummies" ...

Thanks again,

Dave

ozitraveller replied on Tuesday, March 04, 2008

Hi

I hope you guys don't mind me sticking my nose in on this discussion.

I'm also wanting to learn about "how to implement CSLA best practices".

Would anyone be able to post a small code example? "A sample is wirth a 1000 words"

:)

Cheers

Ozi

glenntoy replied on Tuesday, March 04, 2008

The link is not for CSLA best practices, but it is an article to speed up learing CSLA .NET
http://www.primos.com.au/primos/Default.aspx?tabid=67
http://www.csladesktopref.com/

ozitraveller replied on Wednesday, March 05, 2008

Thanks glenntoy

I've done a couple of csla apps, so far, and I seem to be ok with it. I'm just looking for a better structure than the Ptracker, either something like that described above or partial classes.

Cheers

Ozi