|
|
Browse by Tags
All Tags » CSLA .NET » Books (RSS)
-
A few weeks ago I posted what was basically a request for input on one aspect of the future of CSLA .NET. I got a lot of really thoughtful and useful feedback and input from that post (and a related thread in the forum). I've also been discussing this with Apress and other colleagues, and I've come to a decision. Starting with version 3.6, CSLA .NET for Windows and CSLA .NET for Silverlight will be maintained in C# only. This will allow me to focus more of my energies on improving the framework, and on providing resources and materials on how to use the framework (in both C# and VB). In the short term this means continuing to finalize version 3.6 and to finish Expert C# 2008 Business Objects (current availability target is December). However , I am willing to take some people up on their offer to help maintain the VB version of the framework, if those offers still stand. The idea would be to have the community keep the VB code base in sync with the C# code base as it evolves - at least for CSLA .NET for Windows. And here's a possible incentive. If the VB code can be brought up to sync by mid-December or so, I will work with Apress to create Expert VB 2008 Business Objects following the C# edition of the book. I really can't do that book in VB unless the framework exists in VB, but if that can happen then I'm pretty sure we can make the book happen shortly thereafter. Contributors will need to sign a contributor agreement, to keep everything clear and legal. And they'll use the current subversion repository and issue tracking database, so I think it should be a pretty smooth arrangement. And obviously contributors will have the undying gratitude of the community :) If you are interested in making this happen, please email me - rocky (at) lhotka dot net - and we'll go from there. I think this should be a good overall solution, hopefully making everyone happy in both the short and long term. Read More...
|
-
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 Read More...
|
-
I get a lot of questions about Expert 2008 Business Objects as to what it will and won't cover, so I thought I'd try and answer at least some of them in a blog post. The book will cover CSLA .NET 3.6. Version 3.6 is the same as 3.5, but with support for CSLA Light and some .NET 3.5 SP1 features (such as the Entity Framework). And along with CSLA Light comes some interesting support for things like an async data portal and async validation rules. But please note that this book will not cover CSLA Light - that's a book by itself, believe me! Here's the tentative table of contents for the book: 1. Architecture 2. Design 3. Object-oriented design 4. Supported stereotypes 5. Stereotype templates 6. Framework Implementation 7. Editable Objects and Collections 8. Data Binding 9. Business and Validation Rules 10. Authorization Rules 11. N-level Undo 12. LINQ to CSLA 13. Persistence and the Data Portal 14. Example Business Library 15. WPF Application 16. Web Forms Application 17. WCF Service Application > The items in green are complete - first draft anyway - and so you can get an idea where I am in the process. Due to space and time constraints, this book will have three UI chapters just like the previous books. So I had to choose which interface technologies to cover - out of the myriad options available: WPF WPF/XBAP Windows Forms asmx services WCF services WF workflows and activities ASP.NET Web Forms ASP.NET MVC Office/VSTO (Word, Excel, etc) Console I want to make sure to cover smart clients, web development and services. While WCF and Web Forms were easy choices (though I do like ASP.NET MVC a lot, it isn't mainstream yet), the choice between Windows Forms and WPF was difficult. But I have to give WPF the nod, because it is a really nice technology, and it really shows off the power of CSLA .NET business objects very nicely. My current plan is to release ebooks that specifically focus on each of the interface technologies not covered in Expert 2008 Business Objects , and some sort of book (ebook or traditional) covering CSLA Light. Read More...
|
-
A couple people have suggested that I might be abandoning VB. Not so! My first love was Pascal - VAX Pascal actually, which was more like Modula II in many ways. What an awesome language! My next love was VAX Basic. Now that VB has structured exception handling in .NET, it has finally caught up to where VAX Basic was in the early 90's. No kidding. Of course after VAX Basic came VB. And after VB came .NET. I love .NET. I love .NET with VB and C#. C# is just VB with semi-colons, but VB is just C# without semi-colons too. I gave up on the silly language war thing a couple years ago, and am happy to let either or both language live or die by the hand of its users. The language thing was distracting me from truly enjoying .NET. When it comes to writing books, it is really important to remember that they fund CSLA .NET. As much as I love what I do, I've got kids that will go to college in the (scarily near) future, so I can't work for free. So when I write a book, I can't ignore that C# books outsell VB books around 3:1 (it used to be 2:1, but the market has continued to shift). I still think it is worth writing a VB edition to get that 25% of the market, but you must admit that it makes a lot of sense to go for the 75% first! It takes several weeks to port a book from one language to the other. The current plan for Expert 2008 Business Objects in C# is October (though I fear that may slip), and with the conversion time and publication schedule constraints, that pushes the VB edition into early 2009. Apress just hasn't put the VB book on their public release list yet, but that doesn't mean I don't plan to do that edition. When it comes to CSLA Light, I'm doing it in C# because of the 3:1 split, and so again am focusing on C# first. Whether I do a VB version of the framework or not depends on whether I decide to write a book on the creation and design of CSLA Light. I may or may not. If I don't write a book on the design of the actual framework, I won't port (and then maintain) the framework into a second language. It is a ridiculous amount of work to maintain CSLA .NET twice, and I really don't like the idea of maintaining CSLA Light twice too. You have no idea how much writing, testing and debugging everything twice slows down progress (and eliminates fun). As wonderful as Instant C# and Instant VB are, the dual effort is a continually increasing barrier to progress. I might write an ebook on using CSLA Light, in which case I'd leave the framework in C#, but create Read More...
|
|
|
|