Wednesday, August 20, 2008
« Fall 2008 community events | Main | CSLA .NET on DNR TV »
CSLA into the future

I've been thinking a lot about the future of CSLA and of .NET, and I'd like thoughtful input.

The .NET platform is, for lack of a better word, fragmenting. We have .NET, the .NET client-only framework, .NET Compact Framework, Silverlight and probably others. All of these are ".NET", but they are all different.

CSLA will soon support .NET and Silverlight. It sort of supports the Client-Only Framework now, but it was just pointed out to me that while it works, there are compiler warnings in this scenario.

For the past 6 or so years, I've been maintaining all my code twice, once in VB and once in C#. This has never been fun, and wouldn't have been possible at all without help from my colleague Brant Estes and from the Instant VB and Instant C# tools. Even with this, the reality is that I have to do everything twice, and test everything twice.

(yes, I have a unified set of unit tests, but there's a ton of manual testing around data binding in Web Forms, Windows Forms, WPF and now Silverlight that can't be automated)

But now I'm faced with a truly horrific future scenario. CSLA .NET, CSLA Light, possibly CSLA CF and CSLA Client-Only. Four versions of the framework. Two languages for each version. Fixing a single bug requiring changing and testing 8 implementations.

Clearly that's not realistic. Not only would it eliminate any fun, but it just isn't practical. I doubt it would be practical even if I made CSLA a commercial product...

Of course I can cut the complexity in half by maintaining the framework in only one programming language.

This is a touchy thing of course. I was thinking Modula II, but I can't find a good compiler for .NET... :)

Seriously though, the clear choice would be to maintain the framework in C#, at which point I run the risk of alienating the VB community. You might argue I should maintain the framework in VB, but (for better or worse) that would almost certainly alienate a much bigger constituency.

The really important thing is that the framework would support both VB and C#. Regardless of what I do or don't do inside the framework, it can be used by either language (and other languages for that matter) equally well. After all, most of the .NET framework is written in just one language, yet it is used by everyone equally.

Right now CSLA Light is only in C#, though I'm testing in both VB and C# to make sure it supports both equally. I haven't tried, but I imagine you can use it from Ruby or Python too, since both of those languages work in Silverlight too.

Another alternative would be to solicit help from the community. For example, perhaps one or more people would be willing to help keep the VB version of the framework in sync over time. That has its own complications, but might be a worthy solution.

This also ties into my book projects. I'm working on Chapter 16 of 21 for Expert C# 2008 Business Objects right now. As with the previous editions, most of the book is focused on the design and creation of the framework itself, with less focus on how to use the framework.

I think a lot of people would actually prefer a book on how to use the framework, not caring so much how and why I implemented things internally. And I'd enjoy writing that book (in VB and C# editions). But as it is, I'm looking at 2-3 months of work to get CSLA .NET 3.6 working in VB (which will have to wait until the current book is done), then a couple months to get the Expert VB 2008 Business Objects book done. That's 4-5 months where I could write a book on how to use the framework. Or perhaps a series of highly focused ebooks. Or something along that line.

I haven't reached a decision, I'm just thinking long and hard. Thoughtful input is welcome, thanks!

Books | CSLA .NET
Wednesday, August 20, 2008 3:15:50 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [44]  |  Related posts:
CSLA 4 version 4.3.0 alpha available
Using CSLA 4: Windows Phone ebook available
CSLA 4 version 4.2 released
Improving CSLA 4 MobileFormatter behavior
Silverlight 6 doesn’t matter
DevCon slides
Wednesday, August 20, 2008 3:27:15 PM (Central Standard Time, UTC-06:00)
Rocky, do what I do.
Drink Vodka and go sleep! Worry about it tommorow.
Sahil Malik
Wednesday, August 20, 2008 4:08:51 PM (Central Standard Time, UTC-06:00)
Premise:

Best practices for CSLA use are to use the CSLA framework as-shipped. There are ample provisions for modifying behavior via overridden classes, methods, etc., so like most integrations, modification of the framework itself should be a last resort.

As long as the statement above doesn't hack anyone off too violently, I think you can move in the following direction while creating no actual damage to anyone, and a minimum of perceived damage.

Maintain the framework itself in C#. I developed exclusively in VB and VB.Net until about two years ago, so I understand the subtle chill that goes up the spine of VB developers, but I also believe that they tend to be a pretty pragmatic group, and they'll get over it.

Modification of the framework itself is defined to be an "experts only" activity, and as such, we're more comfortable with the idea that these experts have to be fluent in both VB.Net and C# if they're in a VB.Net shop. I don't think this is too far-fetched.

I also think this opens the door to a discussion of documentation (including the books). Some subset of the users of CSLA just want to use CSLA - they're never going to tweak any code, and that's perfectly appropriate. For these users, they're far better served in understanding implementation best practices, including how best to upgrade-proof their applications, vs. understanding the inner implementation of the framework code itself. Maybe at that point, the "how it's built" stuff turns into an e-book or something for the hard-core guys who what to step through the framework.

To summarize, the framework becomes a DLL with source code available, rather than source code that you can compile into a DLL.

As is always the case with such comments, this is just my opinion, so flame away....
D. Lambert
Wednesday, August 20, 2008 4:43:04 PM (Central Standard Time, UTC-06:00)
Rocky

I agree with D.Lambert. I have used your framework for several years now, with great success, and I haven't once needed to change or enhance the framework, other than what I have been able to do via sub classing. Sub classing a C# class in VB.NET (or any other .NET language for that matter) is still possible.

From my experience on the forum and in my own work, providing books/booklets about how to use the framework and especially, hammering into stone, the meaning of designing object models based on responsibility instead of data, is much more needed by both newcomers as well old timers, than the delicate details about the implementation of the framework.
Not that these implementation details aren't important (they really are, when something isn't working), but as Mr. Lambert mentions; put that in a book that for the experts and still provide the source code for debugging.

CSLA has become so mature and well respected today that most newcomers want to use it right away to get their applications build quickly without fully understanding the nitty-gritty details of the underlying implementation.

Lastly I'll prefer that you skip the VB version of the framework and just do it in C#. Most VB programmers have no problem understanding/reading C# code. It's much better than you one day find that it's become so overwhelming that you'll either skip support for one of the .NET platforms, that you mention, or it becomes a commercial product.

However, if you decide to keep the VB.NET version and need help maintaining it, count me in as a helping hand for that.

Cheers
Henrik
H. Laursen
Wednesday, August 20, 2008 4:47:33 PM (Central Standard Time, UTC-06:00)
Why not move the framework to C# only and the books about building the framework in C# only - which makes sense if the framework is only maintained in one language. Most people will not tinker with the framework much.

Then write the book about using the framework from apps point of view in a variety of languages depending on the app audience - VB.NET for a desktop example, VB.NET or C# for a web app example, C# for a Silverlight example. This will accommodate the VB.NET audience who are probably mostly desktop and web developers.
Cade Roux
Wednesday, August 20, 2008 5:26:57 PM (Central Standard Time, UTC-06:00)
I agree with D Lambert's comments as I use CSLA but have rarely had need to change the framework and doing so would always be a last resort. It would not be a concern to me if CSLA were only available in C#. I'm tired of all the C# vs VB.NET arguments, it really doesn't matter.

With the fragmenting you describe and the versions needing to be maintained and tested, no one could justifiably complain about dropping VB.NET. I'm still amazed that such an excellent framework that is constantly being maintained and improved to keep pace with the .NET Framework is available Open Source. I'd choose this to continue at the same rate at the sacrifice of one language being supported anytime.

With regards to books it was great to read the CSLA 2.0 book from cover to cover but I no longer have the luxury of time to read a 1,000 page book. There are way TOO many things to keep up with these days. I can read the code to see what the inner workings of the framework are doing, I'd rather a book focussed on how to use the framework.
W. Roberts
Wednesday, August 20, 2008 5:30:47 PM (Central Standard Time, UTC-06:00)
With the above people, I've learned the most productive way to use CSLA is to not mess with it. Leave it 'as-is' out of the box. This should be the subtitle of your book.

I've said it before and I'll say it again: PT needs to retire. It's not real word enough for people (at least the one's I've had to really educated on CSLA) to grasp. I'd make a new project that can really shine on what CSLA does that no other framework does (in particular things that are harder using ORM tools since I'd say that's your biggest competitor, IMO). This will be key in understanding the difference between data driven, DDD/ORM and CSLA and maybe help get some of these folks who aren't realizing just how powerful CSLA is started using it. I personally think you lose a lot of potential (knowledge) investors with PT because so many of these folks I talk to totally miss the real features in CSLA; the business rules preventing saving, the ease of physical n-tier implementation, the n-level undo, the built in authorization mechanisms...all they see is the 'data access' portions, close the book, and say 'yup, don't need it, got Spring.NET/NHibernate/StructureMap/etc for that'.

As far as time - contract it out - use donations from the site, or something like that. Maybe off-shore it to India? I hate India doing really any of our work - but if they want to grunt translations from C# to VB all day long - that's a good role for them.

I'm a C# guy, but definitely don't shut the door on the VB people - most people in our locale are VB'ers - this would definitely be a big turn off to them.

As far as four versions. All the smart minds in here --- we got to be able to help find some sort of architectural change to limit the amount of moving parts. I know SilverLight will be a challenge no matter what as well as anything for the compact framework - but there's got to be some fat that some of these guys can help trim for you...I know your a fricken genius and everything - but there's some others floating around in here that have helped me out in the past - maybe getting you all in the same room could do some good? I don't know.

Anyway, if nothing else I'm 100% behind whatever you do as long as you keep delivering such as awesome framework.
Brian Johnston
Wednesday, August 20, 2008 6:39:28 PM (Central Standard Time, UTC-06:00)
I'm with what everybody else said.

I'm actively encouraging my developers to use a black box approach with CSLA - we take what the framework gives us, and then extend as needed through subclasses. Even then, our extensions are as minimal as possible.

Primary reason for this is that we want to be able to upgrade CSLA easily. If we start fiddling with the inner bits of CSLA, we'll have to add those changes back into every new release of CSLA.

In terms of the VB vs C# side, Rocky, I think you need to appreciate that many CSLA users these days are just that - users.
You as the author of the framework should realise that CSLA has moved from being a co-op based affair to being a legitimate, respected framework provider.

As a CSLA "user", I like being able to debug through the CSLA source code when I have issues, but otherwise I trust that the framework - as a product of years of evolution and a smart guy's take on business object orientated development - is an assembly of good quality.

So yeah, more "how to"/usage focused books with say one C#-orientated book explaining the framework would be ideal imo.
Paul
Wednesday, August 20, 2008 8:01:12 PM (Central Standard Time, UTC-06:00)
My thoughts come down to the two reasons why CSLA exists in the first place:

* A way to demonstrate what a business object is, and what one should do. (first?)
* A framework that people use (second?)

For that reason, maybe you still need VB, C#, and maybe even in the future F#, IronRuby, and IronPython implementations of the core framework... i.e. the one that runs in normal Windows.

Now, for the parts of the framework that extend it to all these other places, the maintenance load is too high, so I would use the language the market is saying it wants, that being C# at the moment. This is the "framework product" part of CSLA, which means the second principle above in that case overtakes the first one, due to the limitations of time and the fact that we are not a software company with a dedicated staff of framework coders.

If the community then wants to do, say, the IronRuby version of CSLA Light, let them do it :)
Aaron Erickson
Wednesday, August 20, 2008 8:44:28 PM (Central Standard Time, UTC-06:00)
I agree with D.Lambert's comments. I have been using CSLA since version 1.x in a number of projects but have rarely had need to change the framework.

In addition to do a "how to" book, here are something more I think are valuable:

* The book should show and explain "how to" use the framework to build applications. Additionally, when discussing on some specific but common topics, probably alternative solutions/approaches can be discussed along. For example, data access strategies, handling concurrency, inheritance hierarchy in business objects, etc. If these topics are written well, it could become a "patterns" collection for CSLA.

* Each release of the framework should include an up-to-date documentation (can be auto-generated) that includes brief but sufficiently elaborated API reference information, probably with some examples, for CSLA developers to refer day-in and day-out; instead of having to check back with the source code on how certain behaviors are working exactly. For example, the default behavior of IsSavable property returns True when both IsDirty and IsValid return True.
William
Wednesday, August 20, 2008 10:14:44 PM (Central Standard Time, UTC-06:00)
I primarily use C# now, but I come from a VB background. Personally I don't care which language you write it in, but one language is definitely the better choice as far as your personal involvement.

People love this framework once they get to use it. Your existing community will stick with you. But you may lose some new people. It might help to drop the language name from the books.

Most of all I think it's more important to make CSLA the best framework it can be. If two languages slows it down or makes it less fun for you, then one has to go.

As far as other people's involvement I think it's a good idea to hand over the language porting. I also think it's a good idea to get other authors involved in the implementation books. I'd love to see what Matthew MacDonald or Billy Hollis could contribute.
Scott Kuhl
Wednesday, August 20, 2008 10:58:52 PM (Central Standard Time, UTC-06:00)
The How to Use e-books would be most welcome. I've bought your last two ebooks and found them helpful. Also, ProjectTracker is intended to be a reference implementation (I think), but I really get the feeling that it hasn't been fully updated to represent the way **you intended** the objects to look. Most obvious example - some objects are using the FieldManager, some aren't. The templates that ship with the code seem really out of date as well.

Again, I'm talking about how you intended the objects to look - not including the backwards-compatibility stuff that you've graciously included. Some info is in blog posts, other stuff is in outdated DNRTV episodses, etc., but it's scattered and/or outdated.
P.J. Wilkins
Thursday, August 21, 2008 12:37:11 AM (Central Standard Time, UTC-06:00)
I'm also a disciple of Lambert on this one.

Although I'm a VB'er and have followed CSLA since the VB6 days, I'd go with maintaining the framework in C# only, along with an accompanying C# book for the framework. It'd be a nightmare for you to maintain in 2 languages the way things are going...

If this gave you more time to concentrate on documenting the use of the framework with a book, in both C# and VB as you say, this would be a great thing in my eyes.

I agree with Brian Johnston that Project Tracker provides only a limited demonstration of the powers of CSLA. Perhaps a new application could be developed, and I'd suggest that we the community would be willing to contribute to a true open source style project.

Perhaps its taking it too far, but the new demo application could be developed to the extent where it became a best practice reference app (unit tests,exception handling,more object scenarios including implementations of GoF patterns etc. (sorry just brainstorming here)), kind of like Microsofts Petshop, only that it would be, erm, good.
Ian Gibson
Thursday, August 21, 2008 4:37:29 AM (Central Standard Time, UTC-06:00)
Well I'm still in the VB.Net world as somehow I still haven't quite made the switch to C# completely. I agree that it doesn't really matter what language CSLA is done in so I'd go with C# and reduce the maintenance burden.

I'd even go further and do your code examples in C# too! VB.net people can work out C# code and C# people can do VB.Net, and the market demand seems to lean massively towards C# currently (job market in UK certainly is) so it make sense.

A book (or e-book) on "How to use CSLA.Net" seperate from the CSLA framework would be most useful for me, with plenty of examples on the different platforms. Now that might end up being a book more about teaching Silverlight with CSLA business objects, or ASP.Net with CSLA but again that's no bad thing.

After all, I don't worry about the CSLA code or my business objects much because CSLA is so great - it's the other things (ASP.Net, Silverlight, Workflow, etc) that I need to battle with.

While I do like to read about the CSLA internals, becauses it teaches me alot about .Net itself, I am in the business of delivering software solutions and a "How to book" is what I really want.

Richard B
Thursday, August 21, 2008 5:55:42 AM (Central Standard Time, UTC-06:00)
I completely agree with D. Lambert and have a followed a similar path. My company has converted over to C#, not that we think C# is better than VB.NET ... all things aside, there are some really *nice* things we miss from VB.NET. The reason for the change? Simple ... hiring. Developers *perceive* C# to be the better language, and many are coming from a Java background ... this seems to just be the natural progression.

As time has gone on ... I look less and less at the Csla code, instead making changes to our code base which inherits from the Csla framework. My suggestion ... just do it in C#!
Matt R.
Thursday, August 21, 2008 6:00:31 AM (Central Standard Time, UTC-06:00)
Would something like this help for the Compact Framework Development?

http://msdn.microsoft.com/en-us/magazine/cc163387.aspx
Josh
Thursday, August 21, 2008 7:56:56 AM (Central Standard Time, UTC-06:00)
I have to admit I'm torn on this one. I agree changing the framework is a bad idea and I use it as is. So the language it's in shouldn't matter for me. But one of the reasons we chose to go with CSLA was it had a VB version and a long tradition with VB. Explaining that is no longer the case to my boss, will be interesting. It was a significant factor in our decision to use CSLA and I'm not sure how it would affect our moving forward. On the other hand, I also understand the maintenance issue and would love to see books on using CSLA.

This is really and old argument, it's like pulling a feature from a mature app. It will cause you a lot of grief. I think your best bet is to keep the VB & C# for CSLA.net and just do C# for Light, CF and Client-Only. Not everyone uses CSLA as is and companies have livelihoods built around it. So if you don't want to alienate any followers, don't take away something we already have. But it's OK to not add the VB support for the new stuff. Just don't take anything away.
Fred Eberle
Thursday, August 21, 2008 8:21:52 AM (Central Standard Time, UTC-06:00)
Rocky,

Your original VB6 book necessarily told the tale of the creation of the CLSA "framework" because the programmer needed to know and understand its inner workings and theory. They were basically re-implementing it in every class module they made!

Times have changed. To be blunt, people really don't need to know how to create the framework from scratch anymore - use of the framework is much more important.

Secondly, dropping the VB version is the right choice if it will free you to implement new functionalty and provide your input on proper design patterns. Either is arguably better for the community as a whole.

-Steve O
Steve O
Thursday, August 21, 2008 8:24:51 AM (Central Standard Time, UTC-06:00)
>I think your best bet is to keep the VB & C# for
>CSLA.net and just do C# for Light, CF and Client-Only.

That is sort of possible, but not completely. CSLA .NET 3.6 has numerous changes that specifically support CSLA Light, and the CSLA Light code directly requires the C# code from CSLA .NET.

So I could continue to have a CSLA .NET in VB, but you couldn't use it if you wanted to use a Silverlight client, a CF client or (perhaps) a Client-Only client. I suspect this would eventually cause a lot of frustration because it would impose a ceiling on users of the VB framework that wouldn't exist for those using the C# framework.

Or it would eventually force VB framework users to _also_ use the C# framework for the server-side elements of a Silverlight or CF app.
Rockford Lhotka
Thursday, August 21, 2008 8:34:56 AM (Central Standard Time, UTC-06:00)
Rocky,

Your time is valuable, keep the framework in one language. Write 1+ books on how to USE the framework in Web, Client Apps, Silverlight in whatever languages are popular, C#, VB.Net, Iron Python...whatever comes up next.

If there is a real desire for the community to keep the CSLA VB.Net/C# version up to date, let the community maintain it. You can still have complete control over the process by only allowing certain commits / patches applied in SVN.

HTH, BZ
BZ
Thursday, August 21, 2008 9:04:49 AM (Central Standard Time, UTC-06:00)
I would like to suggest that the fracture is actually more insiduous than what you have suggested in this post. It seems to me that the various divergent UIs that CSLA is attempting to support is another layer of seperation. Trying to have objects that support Web, Winforms and WPF (to name a few) cause the framework to become much more complicated and to have implementations that are not ideal or are completely unnecessary for the objects not using all of the frameworks. Additionally it causes your business objects to have code on a remote application server that support these various UI frameworks but will clearly not ever need it.

It might be fair to say that the various divergent forces are (at least)
Language : C#, VB, other
Frameworks: .NET, Mobile, Silverlight, other
UI Support: WPF, Winforms, Web, Mobile, Silverlight, Workflow, other

And ideally your objects would target only the frameworks you wanted to support only in the places you wanted to support them. But running through the core of CSLA is a consistent set of business object code that is the heart of what you are always wanting. It is also (arguably) the core of what you are trying to write about in these books and what people really need to understand the most about creating business object frameworks.

Perhaps I'm talking about CSLA 4 or 5 or maybe even 10 but I just wanted to throw out an idea that might make managing all of these divergent forces more reasonable.

You might consider taking a mixin approach, or aspect based approach. Perhaps a tool like Spring.NET or Aspect# could save the day? I'm just thinking out loud right now but I'm wondering if you couldn't author your base classes completely free of external framework / UI concerns which would make authoring your books and maintaining the core in multiple languages much more reasonable. It might also drastically simplify the core of CSLA. Of course the mixins would probably complicated the upper levels significantly (if it's even possible)...

I imagine this to be, practically, something like this:

[UISupport(SupportType.WPF)]
public class Example : BusinessBase
{
}

Where you get everything you need to make a basic business object from BusinessBase but when the dataportal creates your object instead of creating your Type directly it will dynamically generate a type (IoC) that inherits from your type (or wraps it) and automatically implements all of the things specified by your mixin attributes. You might even be able to do this with core CSLA features such as SupportsValidation, or SupportsEditing etc.

I guess what I'm suggesting is that, perhaps removing from the core of all that is incidental to actual business objects might make maintenance more manageable and perhaps even for multiple languages. Mixin support for various external dependencies could be componentized and be more easily developed by contributors.

... and it would be fun :)
Justin Chase
Thursday, August 21, 2008 11:18:42 AM (Central Standard Time, UTC-06:00)
I think a book on how to use CSLA is a great idea, but speaking for my-self, I would really miss the explainations of the inner workings. As for asking for help to maintain the VB code (I work in / prefer c# also but can do VB), sign me up!
Sean Rhone
Thursday, August 21, 2008 11:50:42 AM (Central Standard Time, UTC-06:00)
You guys are all so nice is makes me kinda weepy. This is too much like an intellectual love-in. Wouldn't it be more fun if we Springer'd it and started throwing keyboards at each other?

I've been using your framework in VB since the first .NET version. Like most here, I don't touch the guts unless absolutely necessary. It is comforting to know that I can easily delve into it, so I would be lying if I said it didn't make me nervous to lose my VB CSLA (including my shiny new Expert VB 2008 Business Objects book). But I sure understand the reasoning.

Maybe this will be the push I need to get out of my comfort zone and move to C# ...

On the other hand - ROCKY - YOU OWE ME BIG TIME! I have invested tons of hours into your framework, bought your books and put up with way to many of Carl's jokes on your DNR episodes. Give me my VB CSLA or I am gonna give you a QWERTY in the eye...
Mike
Thursday, August 21, 2008 11:53:37 AM (Central Standard Time, UTC-06:00)
Here's another vote for maintaining the code in a single language - C#. I hadn't thought of it at first but an earlier commenter pointed out that your time is too valuable to be spent just maintaining separate code bases. Too valuable to yourself and family, but also to the community. I'd rather see your mind working out new solutions to new problems than on converting C# to VB.net.

Perhaps the separate languages could be a community effort.

Lastly, I too would love to see a reference on how to use the framework. I'm fairly comfortable with it, but bringing other devs up to speed is not my strongest point.
David Martin
Thursday, August 21, 2008 1:31:30 PM (Central Standard Time, UTC-06:00)
How would all you C# guys feel if Rocky were to right it in VB instead and get rid of the C# code. Be honest, you say it wouldn't matter but would you feel that way if he were going to just do it in VB only?

I would be willing to bet Rocky would get a different response. How about it Rocky, make the one language VB instead of C#.
Fred Eberle
Thursday, August 21, 2008 8:51:01 PM (Central Standard Time, UTC-06:00)
Writing the framework in C# only makes sense. I understand that there will be some VB folks whose lives will be ruined by this but I, for one, am willing to make that sacrifice! I'd rather you focused your efforts on making one great product (which it is) than duplicating your efforts. I also agree with writing books about implementation rather than the plumbing of the framework. You can use xml documentation to document the code which should be sufficient. I'd rather see that than read a book as it allows me to get to what I need quickly (lots of good examples please).
Lacota
Friday, August 22, 2008 8:05:19 AM (Central Standard Time, UTC-06:00)
Keep It Simple Silly...

- All frameworks in C# only.

- Book on the framework creation - in C# only.

- Book on how to actually USE the framework. Do an Apress or Wrox style with separate C#/VB editions or just one book with sample code in both languages like Wrox's ASP.NET book. This alone, would up your adoption rate significantly.

- Go Commercial! Yes, I said it. This too would up your adoption rate because mgmt would now feel more comfortable buying into it, literally. There is a LOT of hesitation from mgmt with OSS/Free code. And from some developers. So between books/tutorials/class offerings and the warm and fuzzy commercial support for mgmt, you could dedicate the rest of your career to making CSLA what you *really* in your heart want to make it. No one expects you to work for charity Rocky. Turn it commercial and take it to the next level, for both yourself AND the community. It's a WIN-WIN for everyone. I don't think anyone would balk at paying a fair price for a license of CSLA.

Hope this helps in your decision making process.
Leigh
Friday, August 22, 2008 12:08:58 PM (Central Standard Time, UTC-06:00)
I agree with most of the above post. Keep one language and if someone wants to maintain the other language more power to them. Also I think a huge percentage now use the framework as is and do very little modification. If they do modification it is for a business purpose and would most likely be covered in a how to use book (like Principals and Identity which I guess would be more Extending then Modifying). I think CSLA has been a god send to most business developers looking to develop complex apps in a short period of time. I think CSLA has become its own living Framework which I know wasn't what you where trying to accomplish when you first started the books.
John Wahlen
Saturday, August 23, 2008 9:32:59 PM (Central Standard Time, UTC-06:00)
How would we like the one-language CSLA to be VB.Net instead of C#?

Honestly, if it were just up to me, I wouldn't give a hoot. I could work w/ a core in VB.Net just as easily as I could C#.

But I'm an architect in a consulting company, and in order for me to get to use CSLA, I have to convince clients, peers, bosses, and six out of seven dentists surveyed that CSLA is the best way to build their applications. This is already more work than I'd like, because most of these people don't make decisions based on real technical merit. They make decisions based on what they're used to, with a liberal injection of misinformation.

The last time I tried to pitch CSLA, I actually had someone say, "Isn't CSLA that VB thing," as if I was talking about writing their application in FoxPro. Like I said, my background is in VB and VB.Net, but these days, we have to acknowledge that there's a stigma surrounding VB.Net that suggests that nothing written in VB.Net can be anywhere near as good as something written in C#. It's not even close to right, of course, but it's hard to deny that the stigma exists.

Personally, I'd like to see CSLA become more widely accepted as a legitimate enterprise architecture, and that has to mean C#.
D. Lambert
Sunday, August 24, 2008 6:25:02 PM (Central Standard Time, UTC-06:00)
I'd like to add my vote to the majority and suggest the framework and books ship in C# only.

I also like the idea of a new CSLA book that focuses more on how-to-use and best-practices-with-the-framework rather than this-is-how-the-framework-works. When I bought the 2005 book I skipped over the implementation chapters and read about how I would use the framework, and then went back and read bits and pieces about the framework that I was interested in.

Specailised eBooks for different languages and framework implementation details is a great idea.

I'm not sure I agree with Leigh that going commercial is necessary either. From my pov, the framework is already well renown in the industry. I'm about to put forward a business case to my new employer to adopt it for a large project. So far I've not met any opposition from my technical colleagues. Word of mouth is very powerful. And the fact that CSLA moves well with times, upgrades in sync with the latest .Net technologies/releases, has a very active and helpful user community, has a proven track record of success across a wide range of projects, and, most importantly, has Rocky's name on it, means pitching CSLA is not a difficult task. I'm not convinced that going commercial will take-it-to-the-next-level. I reckon it's already flying beautifully under the currect license arrangement.
S Nesbitt
Sunday, August 24, 2008 7:10:40 PM (Central Standard Time, UTC-06:00)
My view is to try and take a bit from all your ideas. First, I would maintain the framework in c# only. Most people use it as a black box so it doesn't matter, People may occasionally look in your code to see how something is implemented, but c# and VB are so similar that people can read the code.

Next I would move the development of csla.NET VB to be a community project. It should only be used for education purposes only. You should recommend that VB developers use the c# version, but use the vb one as a reference material. This way you don't have to worry that additional bugs have been added to the VB community project.

Then the books, I like the idea of having separate books for implementing and using the framework. Using the framework would of course have to be done in both c# and VB. Implementation could be limited to just c#. As you've said about a Java book before, it's the concepts not the code which is important. Perhaps after you've finished writing it, you could get someone else to translate it into VB.

Chris M
Monday, August 25, 2008 2:48:33 PM (Central Standard Time, UTC-06:00)
Rocky,

I agree with the others. Just maintain the framework in one language. I've only ever made small modifications to the CSLA 1.5x versions. I have never made changes to the 2.x and 3.x versions. I would prefer that the book have less text on building the framework and concentrate more on using it.

Jon
Jonathan Miller
Tuesday, August 26, 2008 7:56:11 AM (Central Standard Time, UTC-06:00)
Honestly Rocky I don't see why you are even giving this a second thought. Write it in whatever you are comfortable with and what you feel best represents you as the maintainer.

Some cases in point. Linus doesn't make a C version of the Linux kernel and a C++ and a Python and a.... you get the point. Microsoft doesn't write two versions of the .Net framework. There is one. Telerik or DevExpress do not write multiple versions of their controls or business framework in the case of DevExpress in multiple languages. CSLA is no difference in my opinion. CSLA is a third party DLL and should be treated no differently in the minds of the developers using it and the developer(s) writing it.

I think the thing that should be taken more seriously when doing any framework like CSLA in one language is extensibility. As long as you provide people a way to extend it to their needs no one should really care.

-Keith

Keith Elder
Tuesday, August 26, 2008 8:36:50 AM (Central Standard Time, UTC-06:00)
I won't worry about framework whether it is written in C# or vb. I agree with you on that point.

My thoughts on Book
Couple of years back, you books have been providing guidance to aspiring and even experienced architects about what kind of thought and methodology goes into building a architecture and framework in M$ world. Still it is one of best materials available on building Architecture and Framework in M$ Arena.
You can have two versions of books, one focused on Architects and one focused on users of framework.
I will bet Architect's version sales will out do the other one.
Vikas Kerni
Tuesday, August 26, 2008 9:32:42 PM (Central Standard Time, UTC-06:00)
Maintain the framework in C#. Regardless of what you do with the "Expert" series, provide a published book focused on usage of the framework in multiple languages. Distribute as a compiled binary with optional source. Provide samples (ideally more real-world than PT) in both C# and VB.Net.
JoshL
Wednesday, August 27, 2008 8:35:27 AM (Central Standard Time, UTC-06:00)
I'm going to agree with most everyone here and say just maintain the framework in C#. I also really like the idea of multiple downloads (binaries only or with source) and multiple books (a 'how the framework is built' book containing the details I mostly skipped over when reading your current books, and a *separate* 'how to use the framework' book which could go into much more examples of how to use the framework, and potentially greatly increase it's adoption)
Stacy O
Thursday, August 28, 2008 9:03:05 AM (Central Standard Time, UTC-06:00)
If the opportunity cost of maintaining CSLA in two languages is getting too high, then I would vote to just keep the core framework in C# and spend more time showing people "how to use" the framework through examples and articles. I think every good .Net developer should know both C# and VB.Net, or at least know how to read the "other" language to understand what is happening, and the two languages are really not that different in structure anyway.

I would strongly suggest you still maintain the ProjectTracker sample application in both VB.Net and C# because that is a reference application and falls into the "how to use" category. In fact I would like to see the ProjectTracker app significantly enhanced to show more complex UI usages and control data binding, including some examples of how to use CSLA when building reports.

As far as the books go, I think if you covered how the guts of CSLA works in C# that should be fine. When it comes to covering "how to use" the framework then I think you should show examples in both VB.Net and C# because that is what the users of the framework really care about. Users want to know "what can this tool do for me to make my job easier and my software product(s) better/faster/cheaper". Most users of the framework probably don't spend lots of time digging into the depths of how the core CSLA framework works, they just want to know the basics and how they can use it to their best advantage when building applications.

When it comes to CSLA code-gen templates like CodeSmith, I think you should definately make sure that the templates to code-gen VB.Net and C# classes are well maintained. As long as VB.Net people can see all the "how to use" examples in VB.Net, and get their business object classes auto-generated in VB.Net then most of them will be happy.

Thank you Rocky for creating an awesome open-source framework, documenting it so well and providing code examples and code generation templates for it. You are one of the premier architects of the .Net world and everyone really appreciates what you do.

Thanks.
Alex L
Friday, August 29, 2008 4:13:59 AM (Central Standard Time, UTC-06:00)
I like to see:

* A focus on the C# version only, as VB users still can use the C# DLL's.
* More focus on how to use it instead of the architecture behind it.
like patterns, best practices....

* A new reference project, like a billing/invoice system as that is pretty
complex with a lot of child objects (invoice->line rows-> invoice items...)
I guess that is a pretty common scenario.

* A commercial version to make it more attractive to those companies that
are against the idea of being dependent on open source solutions.

* Create a forum where users can post "best practices/patterns" ideas
like how they structure their projects, how they code-generate their classes.
Like "Here's how I do it...." as sa way to share best practices between users.

* Have someone publish tutorials on best practices when code-gen classes.

//Andy
Andy
Sunday, August 31, 2008 11:14:41 AM (Central Standard Time, UTC-06:00)
Rocky,

Well, I may stand alone on this subject, but I feel that it is important to deliver CSLA in VB and C# as well as other possible languages like F# (as someone else mentioned). I also believe that it continues to be important for you to explain the inner workings of the framework as well as how to use it. I, for one, was drawn into CSLA and evangalize CSLA to this day because of the detailed explanation you provide. In my professional role I find myself working with customers to improve their development processes - a large part of which is framework development. I always insist that the customer purchase a copy of the latest CSLA book and have their developers and development managers read it. Then, and only then, can we have an educated discussion about frameworks, etc. Your books is an essential training tool and without it I would have an incredible time trying to "sell" developers on using CSLA or CSLA-hybrid frameworks. But, after reading your book not a single developer has ever disagreed. Why? Because you answered their questions, addressed their concerns, belayed their fears and espoused the merits of the CSLA approach. We can't live without it.

HOWEVER! I do not believe that it is worth YOUR time to produce an encyclopedia of books in order to cover each language, UI technology, etc. I truly believe that CSLA has grown to the point where you have earned the right to delegate.

So, Rocky, my suggestion is that you focus on continuing to advance the framework in whatever base language and technology set you are most comfortable. Then, sub-contract the other work or let the community rise to the occasion or both - sub-contract from the community :-). I'm sure there are many in the community who could take your base framework and adapt it to VB (or F#, etc.) then help to compile the content for the VB edition - with your supervision, of course, which would take much less of your time.

I personally like the approach you have said you are taking with the 2008 book and focusing on the framework itself in the main book then releasing addendums that focus on how to use the framework with a particular UI technology. For those in the community that are only interested in how to use CSLA out-of-the-box are satisfied by purchasing only those editions while those of us that are interested in what's under-the-hood (and what's inside your head) can purchase the Expert XYZ 2008 Business Objects in whatever language we prefer. Everyone is happy and you don't have to lose your mind trying to know everything!!!

As I said, what matters the most to me is that I have your books as a resource and training tool so that I can be successful in my job and in my efforts as a development lead, architect and technical-evangelist.

Keep up the great work!
SonOfPirate
Monday, September 01, 2008 8:39:55 PM (Central Standard Time, UTC-06:00)
Being in the position of getting started with CSLA, I don't think there is enough material available on how to use CSLA. A broader example app covering more situations is nessecary I think.

In terms of priorities for Rocky's time, the more time he has to advance the framework the better, and this seems more important than a VB version. Better "how to" material might reduce the hours required for forum and email too.

Ashley
Ashley
Tuesday, September 02, 2008 4:29:07 AM (Central Standard Time, UTC-06:00)
I have been programming VB since '94 and have been using Rocky's solutions since '97 - yes I still have a copy of Professional Visual Basic 5 Business Objects on my desk. I have seen C# and VB move closer together, so much so that I now quite frequently convert tools and utilities from C# into VB2005 (I have a VB2005 version of the ErrorWarningInformation provider if anyone is interested). Have been using CSLA.NET 2.14 for almost a year now. So for me, if I needed to view the framework source, doing so in C# wouldn't be a problem.

Although having access to the source (in any language) is nice to know, in reality I have rarely visited the early chapters of Expert VB2005 Business Objects. Like many posters, I have concentrated on later chapters and implementing business functionality (life is just too short!). I have found myself on a number of occassions attempting to bend the CSLA.NET framework, only to find that the framework provided the functionality anyway - I hadn't read the documentation properly (or more likely had read and forgotten it!). Like other posters, I would much prefer a more more detailed book dedicated to implementing the framework in VB and C#.

One of the goals behind CSLA.NET is "so that a developer can focus almost entirely on business logic and appliction design, rather than getting caught up in 'plumbing' issues." (please forgive the plagiarizm ;-). If this is taken to it's logical conclusion, why would a business developer need to see the framework source code anyway?

The issue about whether to charge for the framework binaries and source is a difficult one. Let me say upfront that CSLA.NET is such an excellent product, that I am sure that it will be worth the money. Without wanting to offend anyone, I get the impression from at least a few contributors to the forum, that some developers are using the framework without any immediate business purpose (i.e. just for the sheer fun of it) but nevertheless make a valuable contribution to the wider community. I suspect these developers may be put-off from buying CSLA.NET, so perhaps the licence could be offered free until the business application using the framework was sold commercially (or even some kind of "Express" edition). This would also be the case for many software developers just starting out (we all started out small at one time...).

In summary -
FrameWork source maintained in C# only. No problem, I have no VB axe to grind.
Framework source available as a separate download if required. Great, but I will probably never get the download.
A separate more detailed book just for implementation. Absolutely.
Charge for the framework. Couldn't agree more, but qualified by the point above.

Go for it!

Steve
Steve Graham
Wednesday, September 03, 2008 12:49:13 PM (Central Standard Time, UTC-06:00)
We code in VB.Net at my shop and I have always enjoyed the fact that you started the framework in VB :)

However, I can't imagine that converting between languages is fun in any way. I wouldn't want you getting discouraged on working with CSLA. So I say go with one language whatever that may be that makes your life easier.

A book that went into greater depth showing how to implement the framework in both languages would be a great help! Also, a section or article on sub-classing to modify the framework would be helpful for us not so good yet at sub-classing people! I would rather have these books after the release of the 3.5/6 book, than a VB version next year.

The VB programmer in me will be sad to see the VB version go, but the business programmer in me knows how much work is involved in trying to maintain one code base, much less two different ones. It appears my investment in Instant VB! will pay off even more now!

Chuck
Vaxman2
Thursday, September 04, 2008 9:47:55 PM (Central Standard Time, UTC-06:00)
Well, I did a quick scan on some of the replies here and notice that some people want the book to have more focus on “how to use” the framework rather than “how it internally works”.

I think that focusing the book on “how to use” the framework would be a huge mistake. Simply put, if you understand how the framework works internally (pluming) then you will automatically know how to use it, the opposite is not true.

If the people using the framework don’t have the capacity or patient to dig deep on what constitute the absolute *core* of the application they are developing then I personally think they should not be developing in the first place.

The book should concentrate on the inner workings of the framework first, then after all that has been covered at length, I would think it would be ok to move on to a book that focus on how to use the framework… But ONLY after the inner workings have been covered at length, and by inner workings I mean not only how it works (bits and bytes) but also explain some of the philosophical reasons behind why the framework was designed the way it is designed today.
Rene
Saturday, September 06, 2008 9:30:15 AM (Central Standard Time, UTC-06:00)
Maintaining a good framwork in one language beats maintaining a crappy framework in two languages. Pick a language already. It's been painful to watch you worry about this issue for so long. I don't care which language you use. Only use one language. Please. The CSLA framework is important to me. I want it DRY.
jsmith
Friday, September 26, 2008 6:52:17 PM (Central Standard Time, UTC-06:00)
Don't worry so much about it Rocky... my thoughts are: "If you can spend more time getting us books, guides, and real-world examples", i don't care what language the actual Framework is in.

As some said above... you really should not be modifing the Framework directly (it is going to kill you in the end with maintainablity) but instead, sub-class it.

Besides... you are giving this to all of us for FREE!!!! Do what ever you suits you the best!!!
ward0093
Comments are closed.