CSLA .NET

I have blogged about some thoughts I have regarding what I may do with CSLA in the future.

http://www.lhotka.net/weblog/CSLAIntoTheFuture.aspx

I welcome any thoughts you may have to offer, thanks!

---

Rocky

Well, I certainly wouldn't mind the framework itself being C# only, since I'm a C# guy.  The idea of two books I think is a good one.   I personally wouldn't want to lose a book describing how the framework itself works.  I just find it extremely useful to figure out how I'm supposed to do something if I know how the framework is built.  But sometimes I do wish there were more detail in how to use the framework.  The ProjectTracker doesn't do enough justice to what Csla is capable of.

Give me just a minute to don the flame-retardant underwear...

 

 

I honestly think you'd be better off dropping the VB.NET version of CSLA.  FWIW, Microsoft generally recommends this "lower-level" type stuff be done in C# anyway.  Sure, you can do it in VB.NET, and I know you're a VB.NET developer.  But who are we to buck The Great Microsoft Directive? 

Seriously, though, I think it will serve you better in the long run to confine your framework programming to one language.  Whether you choose C# or VB.NET is up to you... but you know the numbers.  I don't care either way, because I can use the framework in any .NET language I choose.

I would also second a book (or even a series of whitepapers, if they take less time) that's more geared towards how to use the framework to build apps.  While I certainly appreciate knowing how the framework works, and know that the current book is an extremely vaulable reference to have, I believe many people would find a "how to use it/best practices/patterns of use" book to be more valuable.  And PT just doesn't show that.  It's not really broad enough to cover all the areas - but maybe more importantly, because you are trying to show different ways of using CSLA, many people get confused.  I've seen more than one person shake their head and say, "Why can't he just do it one way?  Which way am I supposed to use this?  Which technique is best for the situation?"  We see more and more of those types of questions in the forum.  While you can argue that the forum might be the best place for those, many people don't want to buy a book on a framework only to find out they have to wade through a bunch of forum postings to figure out how to use it.

(And the introduction of managed fields and other improvements in 3.5 has only served to make some of those discussions more confusing - especially when the framework creator admits he mixes his techniques.  )

For better or worse, the trend coming from Microsoft seems to be that the API, and using that API in your application, is more important than knowing the dirty undercarriage of the technology you're using.  Others will disagree with that, and I do to a certain extent.  But the bottom line is that the main reason many folks use the framework is to save them time in building apps - without having to know all the gritty details.  IMHO, that's not the best position to take, but we only have so much time in the day.  And this push from MS has shifted the view of many programmers away from the more technical guides, and into more "how-to" type books.

- Scott

I have been a VB.Net developer until my last project which was C#.  I must admit that I find the VB development environment friendlier that C# but must concede that there is a undeniable tide toward C#.  I think that if you had just one version of the framework and it was in C# that would be fine but I would like to see more in the way of samples, templates, and books regarding the use of the framework in both C# and VB.  Most of us do not need to mess with the framework.  I would think and if we are in the debug mode even those who do only VB should still be able to follow the C# code.  If there are those who really need or want a VB version of the framework maybe they could  become a part of the community that does the conversion.  In the long term you may consider turning over the whole thing to some kind of CSLA freeware community unless you want to continue to support it for your retirement.  Perhaps you would prefer to fish or something else.

Rocky,

I have been VB developer since the beta days of .net.  I met you at briefly at TechEd 2005 and jokingly commented that C# was for amateurs!  I have since ventured over to the dark side and realized that the grass is actually greener over here! I would welcome a C# only version of the framework, as well as a few other important PR related features.

I've used CSLA for years, but I'm not the best at teaching others about why it is so useful. When I hand developers an 800+ page book on CSLA, they instantly shy away because of the perceived effort it will take them to learn something new. The only way for me to initially keep them interested is show them some cool and well groomed user interface that I’ve written that uses CSLA on the back end. (Cool and well groomed aren’t really the adjectives I’d use to describe the Project Tracker application.) During the presentation my audience first notices the error provider icons, and then the undo features. I jump into code and their interest is maintained by the absence of any business logic in the code behind and how bare the UI class ends up being. After discussing other advantages of CSLA, with any luck by that point they’ll start reading the book. However, more times than not they’ll come back a few days later and say….”Well I keep reading the book and it explains how the framework is built, but I still haven’t learned how to use it”.

Considering myself an architect (I attended your session this year on “The Making of an Architect” at TechEd, so I’m not sure you’d consider me one! J), I find it VERY valuable to know how it’s built. But for someone just learning CSLA, someone with a project manager on their back each day demanding results, I think it’s more important to give them some quick wins in the way of being able to show what they’ve learned. They could then be more optimistic to their project manager that they are on to something good and the time they’ve spent hasn’t been wasted.

So a C# only version of CSLA, more examples, and a snazzy new Project Tracker application seems like the way to go to me. The time saved from maintaining the VB versions would give you faster turn times on documentation as new features are added.

Thanks for all you do!

Shawn Camp
www.linkedin.com/in/shawncamp

 

---

Shawn Camp
Principal Consultant
www.linkedin.com/in/shawncamp

I like the 2 book idea (1 for framework description and 1 for more in detail on how to use CSLA/patterns and all other suggestions). Maybe in that how-to-use CSLA book you could incoroprate 4-5 chapters on how to use CSLA with different UIs which is causing space issues in the all around book you are currently working on.

Being a C# developer I don't mind about the absence of CSLA in VB but I think having the community support a VB version would be a good idea. There are some very capable people in these forums that are using VB and I am sure there will be interest in taking up the challenge.

I've used VB.NET for years, only recently switching to C#.

I found the transition to be trivial.

If I had to vote, I'd vote for a 2nd book that has several examples of the framework being used to solve real world problems.   The 1st book containing the design and implementation of the framework with a PT example is fine.  A 2nd book with more complete applications would be better.

Since you will likely be writing this second book may I make a suggestion as to an important addition?  I absolutely lose my MIND over implementing some sort of logging - I'd love to have that written into the framework.

What I mean is that I've got a Configuration object with several child collections.  Any time a value changes on an object I write a message like this to a log table "User #1: First Name value changed from "Rocky" to "MadGerbil".  I record the date, the logged on user's name, and logtype (for easy filtering) and so forth.   This gives me a headache because I want to log when a User is created as well (before the User#, which is an autoincremented field in the database) is assigned.  Also, if you undo the logs entries have to undo as well.  All the child objects are writing to the root objects log collection (ideally).

Anyways, I love some of the things you did in the PT UI, I'd like to see more examples of what can be done - even if it is all in C#.

 

---

<:3 )~~

I am a VB.Net developer. I would prefer you maintain the framework in VB.Net rather than C#. But I am in the extreme minority on that viewpoint. I can see the writing on the wall. So I can live with a C# framework as long as I can use VB.Net code to inherit from it and write my BOs the same way that I do today. I also agree that having 2 books is a better idea. And a better application which shows the *best* ways to use CSLA (rather than a mixed app that shows *every* way to use CSLA.)

Joe

 

Me too, I am a VB developer and I agree at 100 %  with all points that Joe wrote.

 

I think that this "extreme minority" is not so small.

 

Dominique

While I am a VB developer, I agree with everyone else, dropping VB support will not have an impact on our use of the framework.

Coming from a vb background, the vb.net version of the book, explaining the innner workings of the framework, was pivotal in my understanding OO.

Now that I have a comfortable grasp on OO I could go either way.  I never alter the CSLA code itself anyway.  And rarely even step into it.  If I need to extend the BusinessBase class I just inherit and extend away.  So linking to a C# compiled dll would work just fine for our vb.net development.

But every once in a while I do like going into your code and borrowing a technique or two to enhance a legacy app that way released prior to our use of the CSLA framework.

I do hate to see the vb version of the book go away as it has helped alot of vb programmers, who weren't necessarily OO oriented, make the switch to OO successfully. 

But I do fully understand your dilemma.  Thanks for all the work you do.  I think everybody will understand whatever direction you take.

JohnB:

While I am a VB developer, I agree with everyone else, dropping VB support will not have an impact on our use of the framework.

I wonder though if it was the difference between having:

 

A CSLA that still had a VB version but... took months and months between releases, where the primary party that is responsible for maintaining the framework is not enjoying it any more, this ultimately resulting in less spend time being spend on development of the framework because of how much of a headache it is to do something twice every time a change is made and thus ultimately resulting in less releases, less features, etc, etc ...

 

To having a CSLA that was C# only, keeps moving forward, is well supported and that new features, functionality and release are regular and guaranteed indefinitely.

 

This may be a too simplistic view of the topic but I think this is the reality of what will occur.

 

 

In terms of where to have a book that describes the framework itself in-depth I would really really really encourage you to keep doing this (I think only having a C# version is fine).

 

It turns out that when I bought your book, I accidentally did so (as I was after a different book) and I was going to return it. I wanted a book on creating frameworks from the ground up, what you need to take into account, the decisions that you come across, etc etc. So when I read the blurb I had to buy it because I had found a book on this very topic. When I got home I quickly started to scanned through the book and saw that it was very much about a framework called CSLA and hence made an assumption that it wouldn’t be the book was going to be a book like ‘how to use dot net nuke’.

 

I was ready to return the book… but then as I was on the train and going to return the book I decided to read the first chapter and I must say I was blown away. Next time I looked up I had gone right to the end of the train line (about 15 stops past where I was intending to go) and the train was starting to go back in the other direction. Guess what, I didn’t mind in the slightest and kept on reading (although I kept a much closer eye on what station I was getting to when I go closer to home).

 

Since then I have not read the whole book cover to cover (although I have read the vast majority of it) but I have gone through pretty much every single every line of code in the framework (note that did take a while). I did it because I wanted to see what was going through the head of someone who was writing a business framework and the decisions that are made along the way.

 

I can say with all honesty that in terms of my knowledge in .net and software design/architecture that buying that book was the best thing that has every happened to me during my career. I know that not everyone cares about the hows and whys, but for me, this has allowed me to go on and develop systems (some of which use CSLA) and frameworks that are used by thousands of people with great success. That book was for me the moment when everything clicked and all the pieces I had floating around in my head come together.

 

Sorry for anyone way has read this… lol… but I think that there is a great deal of value in a book that talks about the hows and whys of building frameworks.

I agree with most here too.  I can certainly live with a c# only version of the framework with more focus on "using" guides in both c# and vb.net.  I'm predominently a vb.net developer with very little experience in c#.  While I greatly enjoy the vb versions of the book and have learned soo much from them, I've never had to make any actual changes to the framework itself, only "extend" some features using inheritance without altering any of the underlying classes.  IMHO the concepts are so clear in the text that it doesn't matter what language the code samples are in, the reader will "get it".  Even if they start with the last version of whichever vb book you decide to release (just because it's vb) to get those core concepts, then moving to the most recent version of the framework I don't think would be that difficult of a transition.  And with the excellent forum here any questions a new reader may have would be more than sufficiently answered in no time at all.

I think that was the original intent of the book; Csla was only meant to be an example framework, IIRC.  Obviously now it's grown to be much more than that.. which I think is what prompted the question from Rocky.  I was looking for exactly the same thing.. but since the book went into so much detail that you get a usable framework at the end, why not use it I thought?  Extra bonus.  I'd buy both books personally, because each version of "how to build the framework" is more and more refined from the real world experience of Csla users.