Rockford Lhotka

Randy Pausch, rest in peace

2008-07-25T11:06:43.6410144-05:00

http://www.msnbc.msn.com/id/25848017/

If you haven't heard the his last lecture, or read the book, you really should. This guy was one of us, a scientist, a thinker, a man of reason. And his speech is incredibly thought provoking and powerful.

The world needs more people like Randy Pausch, and it is sad to think we now have one less.

Nice list of things people should know about VB

2008-07-21T08:55:36.7956112-05:00

http://msmvps.com/blogs/kathleen/archive/2008/07/19/what-a-c-coder-should-know-before-they-write-vb.aspx

Serious challenge for unit testing in Silverlight

2008-07-17T23:44:51.754-05:00

If you've tried to do any unit testing in Silverlight, you may have run into an interesting issue. Many times, unit tests expect exceptions. Tests are written to ensure that an exception occurs as expected. That's a standard concept in most unit testing frameworks for .NET.

In Silverlight, there's an "expected CLR behavior" where the debugger will break on exceptions that are actually handled by user code - treating them like they aren't handled. See this thread for some more detail:

http://silverlight.net/forums/p/20678/72377.aspx#72377

The result of this, is that you have to employ some ugly workarounds, or you need to press F5 for each of your tests where you expect an exception.

We're running into this issue in a big way with CSLA Light (CSLA .NET for Silverlight), because we're creating lots and lots of unit tests, and a fair number of them are testing to make sure exceptions occur when we expect them.

Of course our unit testing framework (UnitDriven) uses reflection to run each test method - just like MSTest or nunit - and so even though we are handling the exception in user code the debugger insists on breaking in the test methods themselves where the exceptions occur.

Again, there are workarounds. They prevent you from using the debugger to walk through your tests - but at least they exist. The whole thing is really sad though - given that this is apparently intended behavior.

CSLA Light preview release

2008-07-15T19:40:52.638288-05:00

I have put a very early preview release of CSLA Light and CSLA .NET 3.6 online at www.lhotka.net/cslalight/download.aspx.

There is no sample app at this point, so you'll have to look at the unit tests in cslalighttest and cslatest to figure out how to use the various features.

Obviously this is very early code, but it is healthy to release early and often, so here we go :)

One side-effect of our work with CSLA Light is that we discovered that testing asynchronous methods is really hard with nunit and MSTest, and impossible with the Silverlight unit test framework provided by Microsoft. And yet in Silverlight, async methods are commonly required, and for parity a number of async features are now also in CSLA .NET. And we need to have unit tests for them.

To address this issue, we ended up creating our own Silverlight unit testing framework, and an add-on framework for nunit or MSTest. This allows us to write a common set of test code that runs in both Silverlight and .NET so we can test both, and establish that we have parity between them.

Earier today, Justin split this testing framework out of CSLA and we put it up on CodePlex, calling it UnitDriven. The CSLA Light project and Magenic are donating the code to the community as an open-source project, because it can be used to build async unit tests for any app, not just for CSLA Light.

Expert 2008 Business Objects tentative TOC

2008-07-15T10:17:28.039-05:00

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. Other Framework Features

15. Example Business Library

16. WPF Application

17. Web Forms Application

18. 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.

CSLA Light data portal options

2008-07-14T10:41:52.355-05:00

While most people use CSLA .NET because it provides support for data binding, validation, business rules and authorization, I personally think the coolest part of the framework is its support for mobile objects. This support is provided by the data portal, which provides both an abstract persistence model for business objects, as well as an implementation of mobile objects with location and network transparency.

CSLA Light will also include a data portal that works in a manner similar to the one in CSLA .NET. In fact, the two are complimentary - the CSLA Light data portal talks to the CSLA .NET data portal, because the client is running Silverlight and the server is running .NET. This occurs when the CSLA Light data portal is running in "remote" mode - meaning it is talking to a remote data portal server.

The CSLA Light data portal can also run in "local" mode, which means that the "data access" code runs on the Silverlight client. In reality, this probably means that your client-side code is directly calling some external service - an asmx web service, a WCF service, ADO.NET data services, etc. So the fact is that the data access is still on some server somewhere, but you aren't using the data portal to get from the client to that server.

As in .NET, when using the data portal in local mode things are pretty simple. A call to the data portal to fetch an object simply results in a call to a DataPortal_Fetch() method in your object, and the object is running on the client in Silverlight. What you do in that DataPortal_Fetch() method is entirely up to you, as long as the object is populated with data by the time the call completes.

When you use the remote data portal there are more options. Things are somewhat different from the existing .NET data portal. The following figure will help explain.

The CSLA Light data portal interacts with a server (probably a web server, though it could be a Windows Server 2008 running WAS) through WCF. That server is running CSLA .NET 3.6, which includes data portal support to listen for CSLA Light data portal requests. Objects are serialized to/from CSLA Light using the MobileFormatter, which is a serializer included in both CSLA Light and CSLA .NET that provides a subset of the functionality provided by the BinaryFormatter (or NetDataContractSerializer), targeted at the CSLA scenario.

On the web server, CSLA .NET 3.6 receives the inbound client request. Any objects sent from the client to the server are deserialized (including any criteria objects or business objects). At this point there are two ways the process will work.

The default option is that the call from the client is "echoed" into the standard CSLA .NET data portal. In other words, if the client calls Fetch() on the data portal, that call is relayed into the standard data portal as a Fetch() request. This means that the .NET data portal applies its normal process and runs in local or remote mode and ultimately creates an instance of your business object and calls its DataPortal_Fetch() method. Remember that this is all happening in .NET on the server(s). The resulting business object is then returned through the .NET data portal to the web server, and from there through the Silverlight data portal to the client.

So by default, the .NET data portal running on the web server (in the diagram) is a pass-through from Silverlight into .NET. The end result is that the Silverlight data portal works just like the .NET data portal does today.

While the default is good and easy, it may not always be ideal. You may not trust the code running in Silverlight on the client. You may be concerned that the code has been compromised, that somehow a malicious user cracked into the Silverlight runtime, mucked around with your code and bypassed your logic. Thus far no one has established that this can be done, but I can understand the concern.

In that case, another option is that the business class (on the .NET side) can have a MobileFactory attribute attached:

[MobileFactory("MyLibrary.CustomerFactory,MyLibrary", "Create", "Fetch", "Update", "Delete")]
public class Customer : BusinessBase<Customer>

If this attribute is applied, the .NET data portal will create an instance of the type specified in the attribute, and will call methods on that factory object instead of on the business object. In other words, a call that would have gone to DataPortal_Fetch() will now go to a method matching the third parameter of the attribute - in this example a method called Fetch().

The factory object is responsible for creating, initializing and returning the object from create/fetch/update operations. Delete returns nothing. How the factory object does this is up to the factory author - you. I suspect a very common implementation will be for the factory method to do extra business checks (validation/authorization) to decide if the client call is valid, and if it is valid then the factory will just echo the call into the .NET data portal. So you might write something like this in a factory:

public object Fetch(SingleCriteria<Customer, int> criteria)
{
// do extra validation/authorization checks here
if (allChecksPassed)
return DataPortal.Fetch(criteria);
else
throw new Exception("Bad client request");
}

A colleague of mine at Magenic, Nermin Dibek, suggested an interesting enhancement to this MobileFactory model, which I'll include in the implementation. As a configuration option, you can specify a "factory of factories" object. The default behavior is to take the type name in the first parameter and use it to create an instance of the factory object. But if you'd like, you can create your own "factory creator" object that takes that first parameter and uses it however you'd like to create an instance of the factory. This would allow you to substitute MyTestLibrary for MyLibrary when you wanted to use a set of test factories instead of the production versions, and that sort of thing.

It is my intent to extend this MobileFactory concept into the .NET data portal itself (in CSLA .NET 3.6), so in a pure-.NET scenario you'd have comparable options, like this figure:

The data portal would default to its existing behavior, which would be unchanged. However, you'd be able to apply an ObjectFactory attribute to your business classes to indicate that the data portal should route its calls to your factory object rather than to the DataPortal_XYZ methods.

The only catch here, is that your factory objects then assume responsibility for managing the status values (IsNew, IsDirty, etc) of the object (and its child objects, etc). The data portal essentially steps out of the picture entirely - leaving you to do all the work of creating and manipulating the business object as necessary. However, this does open up some interesting alternatives for persisting objects even though the solution is less automated than the current implementation.

The CSLA Light part of what I've discussed here is in the current 3.6 code in Subversion (svn://svn.lhotka.net/csla/branches/cslacs36 and svn://svn.lhotka.net/csla/trunk/cslalightcs). The ObjectFactory support for CSLA .NET itself will probably happen in a few weeks.

DNR TV show on CSLA .NET 3.5

2008-07-11T10:16:28.5628928-05:00

You can watch the first of (at least two) dotnetrocks TV shows about CSLA .NET 3.5:

http://www.dnrtv.com/default.aspx?showNum=116

In this show I got about half way through discussing the major changes from version 3.0 to 3.5, so Carl and I will need to record another show to finish the discussion.

VS Live New York and Las Vegas

2008-07-01T15:19:06.8525664-05:00

VS Live is coming to New York in September and Las Vegas in October. I'll be speaking at both events, including a pre-con workshop covering architecture and design considerations for .NET 2.0 through 3.5 - kind of a survival guide to the many versions of .NET :)

Of course I use CSLA .NET and CSLA Light to illustrate some of the techniques you can use to minimize your risk and lower your costs as you migrate from Windows Forms to WPF or Silverlight, and from Web Forms to ASP.NET MVC or Silverlight. At the same time, I spend a lot of time talking about most of the various technologies available - my use of CSLA is incidental rather than central to the talk.

1105 Media (the people who run VS Live) put together this promo video for the show - I'm in the middle of it for a bit.

VS Live is a great show - I hope to see some of you in one of these cities!

Twin Cities User Groups for Developer Geeks

2008-06-25T22:03:29.3785936-05:00

It is a good time to be a developer/software geek in the Twin Cities!

Developer's Guild - the art and science of building software
XNA user group - building games on the Microsoft platform
Languages user group - for that inner language/compiler lover within each of us

I'll be speaking at the Developer's Guild on August 12, giving a preview of CSLA Light (CSLA .NET for Silverlight) - probably its first public showing.

CSLA Light data portal and n-level undo

2008-06-24T23:24:09.078-05:00

With serialization largely out of the way - or at least under control - as described in a recent blog post, we've been able to put some focus on a couple other key areas.

N-Level Undo

The n-level undo functionality in CSLA .NET relies on reflection against private fields. Obviously that's not possible in Silverlight. Fortunately the serialization scheme we're using means that there's already a mechanism for trapping the values stored in the field manager. And there's the OnGetState()/OnSetState() methods that allow a business developer to trap/restore values in their private fields (if they choose). So UndoableBase had to be altered to use these techniques rather than using reflection. The end result is the same, which is what really matters.

We opted not to replicate IEditableObject into CSLA Light. It is a .NET interface used by Windows Forms data binding, and is the source of never-ending pain thanks to all the edge cases and idiosyncrasies around this, seemingly simple, interface. Of course the interface isn't used by Silverlight (or WPF), and so isn't necessary. The effect of this choice is to simplify quite a bit of the n-level undo code, while at the same time preserving the shape of the pre-existing public interface for all objects. In other words, BeginEdit(), CancelEdit() and ApplyEdit() work as expected, but you can't use IEditableObject to get at its versions of those methods.

Justin just ran into a strange issue with BusinessListBase, where an attempt to iterate through the items in the list caused a strange runtime exception from somewhere deep in the bowels of the Silverlight runtime. It appears there's some issue with a subclass of a collection iterating through its own items in a foreach loop. A for loop works fine however, so we have a workaround.

Ultimately however, the ability to easily implement a Cancel button, including when using modal dialogs (which can be simulated in Silverlight) is supported

Data Portal

The data portal is coming along pretty well too. It supports a provider model, conceptually similar to the data portal in .NET. And we currently have two providers: local and WCF.

One issue we're facing here is that Silverlight has no configuration subsystem comparable to System.Configuration. So there's no easy way to get configuration data from an "app.config" file or equivalent. At the moment I've come up with a code-based configuration scheme - but (unless Microsoft puts out a solution soon) we'll probably end up creating some embedded resource-based configuration subsystem of our own.

The data portal itself is asynchronous. This changes the way the UI code interacts with the data portal when compared to .NET code. Rather than just calling DataPortal.Fetch() to get an object, in Silverlight the UI must call a BeginFetch() method to start the process and handle a completed event to process any results when they return.

This means the UI code looks something like this:

var dp = new DataPortal<MockEditableRoot>();
dp.FetchCompleted += new EventHandler<DataPortalResult<MockEditableRoot>>(dp_FetchCompleted);
dp.BeginFetch();

This code starts the process, and the dp_FetchCompleted is invoked (on the UI thread) when the call is complete:

private void dp_FetchCompleted(object sender, DataPortalResult<MockEditableRoot> e)
{
this.DataContext = e.Object;
}

Alternately you can wrap this code into a factory method and completed event provided by the business class. That is a little closer to the typical CSLA .NET model - but is still async, and the UI still must handle the result in a callback event handler.

Local Data Portal

When using the data portal in local mode, it calls DataPortal_XYZ methods, much like the .NET data portal. There are a couple interesting differences however. The first being that the DataPortal_XYZ methods must be public in scope. Remember, no private reflection, so only public methods can be called.

I debated about using an interface-based approach, but decided against it for a couple reasons. First, it would be dissimilar to the existing .NET approach. Second, it would mean that your DataPortal_XYZ methods couldn't be strongly typed - they'd have to accept parameters of type object and you'd have to cast them to something meaningful.

The second difference flows from the fact that most server-related activities in Silverlight are asynchronous. Most DataPortal_XYZ methods, therefore, will be invoking async server calls and getting the results from a callback event. So all DataPortal_XYZ methods are provided a delegate they can use to do a callback to indicate completion. In a simple (synchronous) example it looks like this:

public void DataPortal_Insert(
Csla.DataPortalClient.LocalProxy<MockEditableRoot>.CompletedHandler handler)
{
LoadProperty<string>(DataPortalMethodProperty, "insert");
handler(this, null);
}

The DataPortal_Insert() method accepts a CompletedHandler parameter it can use to indicate completion. The call to handler() is the completion call, and the first parameter is the resulting business object, while the second is an Exception object if you want to indicate failure.

In an asynchronous example things are a bit more complex. And the async scenario is the most common. Typically when using a "local" data portal you'd be doing so because you want to call some web service or data service from Silverlight. And since all the server call technologies in Silverlight are async, your DataPortal_XYZ method will almost certainly be invoking some async service. So more normal code might look like this:

public void DataPortal_Insert(
Csla.DataPortalClient.LocalProxy<MockEditableRoot>.CompletedHandler handler)
{
var svc = new Csla.Testing.Business.TestService.TestServiceClient();
svc.InsertDataCompleted +=
new EventHandler<Csla.Testing.Business.TestService.InsertDataCompletedEventArgs>
(svc_InsertDataCompleted);
svc.InsertData(GetProperty<string>(DataPortalMethodProperty), handler);
}
void svc_InsertDataCompleted(
object sender, Csla.Testing.Business.TestService.InsertDataCompletedEventArgs e)
{
var handler = (Csla.DataPortalClient.LocalProxy<MockEditableRoot>.CompletedHandler)e.UserState;
handler((MockEditableRoot)e.Result, e.Error);
}

This looks a bit odd, but after you do a bit of Silverlight programming this pattern becomes second nature.

The DataPortal_XYZ method sets up and starts the call - passing parameters to the service, and one parameter that is "user state", which is extra (doesn't go to the server, but stays on the client). Notice that before making the InsertDataAsync() call, which is the call to the service, the code hooks the InsertDataCompleted event - this is the event that will be raised (on the UI thread) when the service call completes.

The svc_InsertDataCompleted() method is the event handler. This is where you write the code to handle the results from the service call. When using the data portal, this is where you call back into CSLA to indicate that the call is complete. Ultimately CSLA will return the result to the UI code, but this mechanism allows CSLA to do any extra processing between the DP_XYZ call and the UI so it can manage the state of your business object.

You can also shrink this by using a lambda:

public void DataPortal_Insert(
Csla.DataPortalClient.LocalProxy<MockEditableRoot>.CompletedHandler handler)
{
var svc = new Csla.Testing.Business.TestService.TestServiceClient();
svc.InsertDataCompleted += (o, e) => { handler((MockEditableRoot)e.Result, e.Error); };
svc.InsertDataAsync(GetProperty<string>(DataPortalMethodProperty));
}

That eliminates the need for a separate event handler method and simplifies the code.

Remote Data Portal

The remote data portal option works very much like the normal .NET data portal, and is generally simpler to use that the local data portal. When the data portal is configured to use the WcfProxy, it will use WCF to communicate with a CSLA .NET data portal on the web/app server.

In this scenario you need a web or app server that is hosting a CSLA .NET data portal - the .NET end of the CSLA Light data portal. The CSLA Light code running on the Silverlight client will call the CSLA .NET code running on the app server.

When using a remote data portal, the Silverlight business object will not include any DataPortal_XYZ methods. The DataPortal_XYZ methods will only be implemented in the .NET code, and will only exist on the server. The client-side code will still call the data portal, but the call will be automatically routed through WCF to the app server.

This is exactly the same kind of behavior you'd get from the existing .NET data portal - you can choose to use a local or remote data portal, but the business object and UI code are the same either way (with the exception that a local data portal requires implementation of DataPortal_XYZ methods).

On the app server, which is running CSLA .NET, requests will come in from the Silverlight client. These requests can be handled in one of two ways.

The default is for the client call to be routed into the CSLA .NET data portal, and the rest of the processing is normal CSLA .NET processing. In other words, a Silverlight Fetch() call results in a DataPortal.Fetch() call on the app server, which runs the DataPortal_Fetch() method just like it always has. The result of the data portal call on the app server is then returned to the Silverlight client.

I call that the "pass-through" mode because the server-side data portal just passes the client call through to the "real" data portal. And this is a great option for when you trust the client that is running the Silverlight app, because it requires the least amount of code and provides the simplest solution.

But if you don't trust the Silverlight client. If you are worried that someone will break into the Silverlight runtime and somehow put bad data into your object's fields (perhaps bypassing your business logic, etc), then extra precautions are required. To address that concern, the server-side data portal can optionally invoke an "observer" or "factory" (I'm still debating the name of this thing).

To do this, on your server-side business object code (in the server-only partial class) you use the MobileFactory attribute to specify the type name of the factory object, and the method names to be called for create, fetch, update and delete operations (the only operations the data portal supports).

[MobileFactory("MyProject.MyFactory, MyProject", "Create", "Fetch", "Update", "Delete")]
public partial class MockEditableRoot

Then you must implement the factory class:

public class MyFactory
{
public object Create(object criteria)
{
    // create, initialize and return new object here
}

public object Fetch(object criteria)
{
    // create, load and return object here
}

public object Update(object inbound)
{
    // insert, update or delete object here
    // return resulting object
}

public void Delete(object criteria)
{
    // delete object here
}
}

The criteria or business object from the client does materialize on the server. Of course on the server it materializes within code you control, and so you can safely interact with the object from within the methods of this factory. Here, you can force re-running of the validation rules, apply extra authorization rules or other processing you see fit - all on the app server. Only if you are happy with the object would you then invoke the "real" data portal to actually allow the persistence to occur.