Rockford Lhotka

 Friday, March 11, 2011

The full draft of the Using CSLA 4: Data Access ebook is now online and available for individual purchase.

If you purchase, or have purchased, the Using CSLA 4 ebook series, you can also download this new ebook, because it is part of the series.

This 214 page ebook (in PDF format) covers the four data access models supported by CSLA .NET, focusing on the two models that provide the best maintainability and flexibility without incurring undo complexity.

The book walks through each business object stereotype, demonstrating how to implement the encapsulated invoke and factory implementation data portal models. It also demonstrates the use of ADO.NET, ADO.NET Entity Framework, and mock database access technologies.

The book includes several sample applications that provide complete implementations of persistence to accompany the concepts and techniques discussed in the book.

Friday, March 11, 2011 3:19:12 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, March 9, 2011

A few weeks ago I posted about my initial efforts to port CSLA 4 to MonoDroid. The idea being that business classes created for WP7 could be used on Android as well.

That inspired some people – which is awesome!

  • Stuart Bale volunteered to help port CSLA 4 to MonoTouch, for iOS (iPhone/iPad).
  • Jonny Bekkum (a long-time CSLA team member) volunteered to port CSLA 4 to mono – the open source implementation of .NET that runs on Linux, Windows, and other platforms.
  • Kevin Ford volunteered to finish what I’d started by getting CSLA 4 ported to MonoDroid (in reality, he’d already started a parallel effort, and then merged his work into mine).

Initial code for all three projects has been checked into the svn code repository. Jonny has some test apps running in mono, so there’s some confidence in that code. Kevin has a small test app running in Android, so there’s some confidence there too (though it is earlier in the process). The MonoTouch port is the hardest of the three due to some limitations of MonoTouch, and we don’t know for sure that the current code works (though it does build in MonoDevelop).

My current plan is that CSLA 4 version 4.2 will be the release that includes support for mono, Android, and iOS – in addition to the existing support for .NET, Silverlight, and Windows Phone. That’ll be exciting!

If you are a developer on any of these three new targets, we’d appreciate any help in testing the code to see if it works, and to find solutions to anything that doesn’t work. Please post any issues or comments on the forum at http://forums.lhotka.net – thanks!

Wednesday, March 9, 2011 5:16:38 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, February 21, 2011

I will be showcasing CSLA 4 at the Open Source Fest at MIX11. That’s Monday evening, April 11.

If you are attending MIX please stop by and say hello, it should be a good time!

Monday, February 21, 2011 9:26:05 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, February 18, 2011

Bxf and CSLA .NET both include a TriggerAction control. This control helps support the MVVM design pattern in WPF, Silverlight, and WP7 applications.

(Bxf is completely independent from CSLA – I donated TriggerAction from CSLA to the Bxf project a while back though, so this type is available from either framework)

The specific problem addressed by TriggerAction is the need to invoke a verb (method/command) on your viewmodel object in response to any arbitrary UI event. One common UI event is something like a button click event, though you can often use commanding in that case. But there are numerous other UI events from many controls other than buttons, and you might want to have one of those UI events cause the viewmodel to perform an action.

TriggerAction basically wires arbitrary UI events to methods on the current DataContext (usually the viewmodel object).

<bxf:TriggerAction TargetControl="{Binding ElementName=MyControl}"
                                           TriggerEvent="MouseOver"
                                           DataContext="{Binding Source={StaticResource vm}}"
                                           MethodName="MyAction" />

TriggerAction listens for the trigger event from the TargetControl. When it handles that event, it invokes the specified method (MethodName) on its current DataContext object. There’s nothing more to it.

To get TriggerAction working you need two things: source and target.

Source:

  1. TargetControl must be set
  2. TriggerEvent may be set (default is “Click”)

Target:

  1. DataContext must be set (or inherited from the container)
  2. MethodName must be set

Parameter (optional):

  1. MethodParameter may be set (to a value or binding expression)
  2. RebindParameterDynamically may be set to true (to force rebinding of MethodParameter to work around issues with certain control properties such as ListBox.SelectedItems)

The most common causes of failure when using TriggerAction are that the TargetControl isn’t set right, or the DataContext isn’t set right, and of those two the most common is that the DataContext isn’t what you think it is (that happens to me all the time).

The method TriggerAction invokes on the DataContext object can accept either 0 or 2 parameters:

public void MyAction()

or

public void MyAction(object sender, ExecuteEventArgs e)

The ExecuteEventArgs class is also defined in Bxf and CSLA. If you use TriggerAction from Bxf.Xaml, you must use ExecuteEventArgs from Bxf.Xaml. If you use TriggerAction from Csla.Xaml, you must use ExecuteEventArgs from Csla.Xaml.

If you are using Bxf and CSLA together it is important to understand that the ViewModel<T> class from Csla.Xaml uses the Csla.Xaml.ExecuteEventArgs type. If you are using the Bxf TriggerAction control, you’ll need to create your own viewmodel types from Csla.Xaml.ViewModelBase<T> to accept the Bxf.Xaml.ExecuteEventArgs type.

Bxf | CSLA .NET | Silverlight | WP7 | WPF
Friday, February 18, 2011 5:31:39 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, February 15, 2011

CSLA 4 is now available through NuGet, the package installer for .NET products.

This is thanks to Johann Hough (jaans on the CSLA forum) - thank you Johann!

The following packages are available:

  • Core
  • ASP.NET
  • ASP.NET MVC
  • Silverlight
  • WPF
  • Windows Phone
  • Windows Forms
Tuesday, February 15, 2011 10:03:29 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, January 19, 2011

I’ve started the process of porting CSLA .NET version 4.1 to MonoDroid. I expected this to be relatively easy because I’ve already got a version of CSLA 4 running on WP7, and from everything I know about MonoDroid it should be pretty comparable (excluding anything to do with XAML and UI concepts of course).

After a couple hours of trying to get the Android emulator to run on my machine, I discovered that the hybrid C++ and Java worlds really don’t “get” Windows. They interpret Windows configuration in different ways. I’m not sure which one is lame and out of date (by around a decade), but either C++ or Java apparently needs help…

Fortunately some googling (with Bing of course Smile) turned up the answer in the form of an environment setting named ANDROID_SDK_HOME that both C++ and Java will honor. The problem is that my User directory isn’t on the C drive, and either C++ or Java can’t handle this concept. Setting ANDROID_SDK_HOME to the path of my actual User directory solves the issue so the emulator works as expected.

The Android emulator is extremely slow, but functional. Just deploying my tiny little test app takes several minutes, and my computer is no slouch. It is clear that Android developers don’t round-trip very fast in terms of running their code to see if it works. I feel sort of like I’m back in 1992 on a VAX where the compile-link-run cycle took minutes. I’m obviously very spoiled with the performance of things like the WP7 emulator or the ASP.NET development web server, where the compile-debug/run cycle takes seconds (at most).

The process of getting CSLA 4 to at least build in MonoDroid took around 4 hours of work. Not that I’m done, but the code does compile at this point. The holdups and issues are:

  1. MonoDroid doesn’t have ObservableCollection and a set of related types, so I’ve started implementing them myself
  2. MonoDroid doesn’t know about “Add service reference”, it only knows about “Add web reference”, and that means I need to create a new data portal proxy/host pair
  3. It doesn’t look like the System.ServiceModel assembly that comes with MonoDroid actually works – my one remaining build error has to do with this assembly – and this probably means some other client-side data portal elements will be affected (like LocalProxy) – I think this indicates some bad factoring on the part of CSLA in terms of the client-side data portal implementation though, so in an odd way this might be beneficial in that the problem highlights a design flaw that needs fixing
  4. There are some bugs in MonoDroid in VS, where setting some project properties “doesn’t take” – change the property values in VS and they aren’t saved to the project file – but edit the project file in a text editor and the changes are honored – not a big deal, and MonoDroid is in an early beta, so this sort of thing is to be expected
  5. There’s no XAML or directly comparable concept on Android, so I’m not even trying to port Csla.Xaml, only the core Csla project – I’ll probably need to create a Csla.Android project with UI components appropriate to the Android UI technology

I mocked up the initial types to implement ObservableCollection, and it won’t take a lot more effort to make them have the functionality required by CSLA. I don’t feel the need to completely replicate those types – only the parts CSLA cares about.

Creating a data portal proxy/host pair isn’t hard, the data portal is designed with this sort of flexibility in mind. However, this will be the first non-WCF proxy/host pair I’ve built on the Silverlight/WP7 code base, so I’m looking forward to establishing that it is as easy as it should be.

The unexpected dependencies on System.ServiceModel are probably the most worrisome aspect of this project so far. I suspect unraveling the dependencies and fixing the design/implementation may lead to some breaking changes in the Silverlight/WP7 code. On the other hand, if my early suspicions are correct, the design is probably flawed and I’ll be able to improve things as a result.

The question is whether I leave the SL/WP7 code alone and just fix the dependencies in the Android code base. That’s probably what I’ll do in the 4.x timeframe, because I really try to avoid substantial breaking changes in point releases…

The loss of Csla.Xaml is not ideal. At the very least I think a Csla.Android project will need ViewModelBase and ViewModel, but I suspect other Android-related UI components may be required.

Anyway, I’m quite impressed by MonoDroid. It seems pretty complete, pretty functional, and pretty well integrated into Visual Studio. Other than my issues with the emulator configuration the install was painless.

To head off this question before it is asked: I do expect I’ll create a version for MonoTouch at some point.

But MonoDroid has a much lower barrier of entry since it installs on Windows and works in Visual Studio. MonoTouch requires a non-trivial cash outlay to buy a Mac, and a non-trivial time outlay to learn the Mac, MonoDevelop, some Mac svn implementation, etc. Where I’ll probably have a working version of CSLA 4 for Android in under 20 hours, I strongly suspect it will take more than twice that long (and a lot of money) to get a version working in iOS.

In this regard I must give kudos to Google, Android and MonoDroid – they have a much lower barrier to entry than Apple currently provides.

Wednesday, January 19, 2011 11:30:11 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, January 18, 2011

csla_logo1_32I am pleased to announce the release of CSLA .NET version 4.1 with support for .NET, Silverlight and Windows Phone 7 (WP7).

You can download CSLA 4 version 4.1 at http://www.lhotka.net/cslanet/download.aspx

Although there are numerous new features in version 4.1, the primary focus of this release is Windows Phone 7. With CSLA 4 version 4.1 you can now author business classes that run unchanged across the entire .NET platform:

  • Windows Phone 7
  • Silverlight
  • WPF
  • ASP.NET MVC
  • ASP.NET Web Forms
  • WCF services (SOAP and REST)
  • asmx web services
  • Windows Forms

The ability to reuse your business layer on .NET, Silverlight and WP7 is incredibly powerful, enabling you to extend your application to users on Windows, the web, and now the phone.

You can learn how to use CSLA 4 to build scalable, flexible, and maintainable applications through the Using CSLA 4 ebook series. This ebook series is currently a work in progress and will be finished in the first half of 2011.

Tuesday, January 18, 2011 7:30:40 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, January 14, 2011

Dunn Training is offering a CSLA 4 training class on February 23, 2011 in Atlanta.

http://www.dunntraining.com/training/schedule.htm

If you are looking for CSLA .NET classroom training, this is a great opportunity. Here’s a quote from a student who attended the December class:

Dunn’s CSLA training was phenomenal!!! It significantly advanced our team’s knowledge of CSLA and helped layout the roadmap for our future development. Mark Berry  holistically demonstrated how CSLA works with MVVM, Silverlight, WPF, Expression, OO Programming and Code Generators. He also successfully answered extremely challenging CSLA questions that were thrown at him during class. Our team is pretty knowledgeable with CSLA and the other technologies, but Mark took us to an entirely new level, sprinkled in some nice tips, tied it all together, and reenergized our team. The training was well worth the money.

Friday, January 14, 2011 5:36:03 PM (Central Standard Time, UTC-06:00)  #    Disclaimer