CSLA .NET

As we work on CSLA Light (CSLA .NET for Silverlight), there's (at least) one continuing point of debate in the team - so I thought I'd gather more input.

One goal of CSLA Light is to allow the majority of your business code to be the same in Silverlight and .NET. The data portal runs between the two platforms, and your business objects literally move from .NET to Silverlight and back again. Very cool stuff!

This means that the same physical class file is included in two projects - a Silverlight Class Library and a .NET Class Library. We do this using the ability in VS to "Link" a file from one project into another, so the file exists once, but is in two projects. Pretty easy once you do it.

That all works nicely - for code that is 100% compatible with CSLA Light and CSLA .NET. This includes your property declarations, validation rules (mostly) and authorization rules.

This does not include your factory methods (usually) or your data access code. Silverlight doesn't even have the data access technologies available on .NET, so that code simply can't compile or work in Silverlight.

What this means is that, for a given business object like CustomerEdit, you could have three types of code:

1. Shared code that runs in Silverlight and .NET
2. Code that only runs in Silverlight (rare but possible)
3. Code that only runs in .NET (data access at least)

So that linked class file will at least contain the shared code.

Using compiler directives like "#if SILVERLIGHT" and "#if !SILVERLIGHT" the linked class could contain all three types of code. It is just that some of it won't compile on Silverlight or .NET obviously.

Another solution is to use partial classes. In this case there'd literally be three different files. The linked one with the shared code, a partial class in the Silverlight Class Library for the SL-only code, and a partial class in the .NET Class Library for the .NET-only code.

Either solution gets the same end result - all three types of code are there. The compiled results are the same either way.

We're really just talking about coding style - which is easier to understand, read, and explain?

Would you prefer to see all your code in one file, with sections blocked out with #if statements?

Or would you prefer to split your code into three files, each one with clear meaning?

(please note that CSLA Light will support either model - but all our examples, etc will be in one mode or the other - we're just trying to figure out what to "recommend" as the best approach)

Your input is very welcome!!

---

Rocky

I think I'd prefer partial classes. 

You could have Person.cs, Person.SilverLight.cs and Person.Net.cs.  All relevant code is tucked away in an easy to find spot, vs. being intermixed with compiler directives, which seem messier to me.

I would vote for partial classes, each file is kept as simple as possible, and you can tell from the file name where the code will end up rather than trying to keep track of where you are in the file in relation to the compiler directives.

Partial Classes are much easier to read and manage than Compiler Directives in my opinion.  Although having 3 different files could be a little confusing, I still think its a better approach.

---

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

I, personally, would also definitely prefer partial classes.

I would prefer partial classes.

Cast another vote for partial classes.

I'll go against the grain here and say that compiler directives would be my preferred approach.

I've been looking through the test harness for CSLALight (which uses the partial class approach) and when trying to follow the code from SL to .Net for a single business object class, I have to have 2-3 tabs open in VS.  After looking at a few business objects, my VS tabs were pretty crowded.

If you structure your code well enough - i.e. use regions and keep your SILVERLIGHT and !SILVERLIGHT sections together, then you have the advantage of all the code being visible in one screen in VS - i.e. just like a normal CSLA.Net class file. 
Such seperation can be enforced easily enough using code templates.

This argument seems semantically similar to an argument one can have about seperating data access code out of your CSLA.Net class file into a partial class. 
Instead the recommended approach for CSLA is to have it all in one class file and use regions and good coding structure to keep the logical seperation clear.

Why go in a different direction with the compiler directives?

Another point is that using partial classes will cause projects to bloat by roughly a factor of 2 in terms of files listed in the VS solution explorer. 
With the size of application I am working on - probably going to have in the order of 300+ business object classes when we done - minimising the number of project files is a key concern for us in terms of readability and management of the solution structure.

My vote for partial class to make life easier. :)

I like the idea of being able to use the same code for both .Net and Silverlight, but doesn't what you are asking seem a bit hackish?   It might be a slippery slope...

mr_lasseter:

I like the idea of being able to use the same code for both .Net and Silverlight, but doesn't what you are asking seem a bit hackish?   It might be a slippery slope...

I don't think so.

We're working very hard to make sure the property declaration, validation rules and authorization rules concepts from CSLA .NET appear the same in CSLA Light. Specifically so those regions of your objects can run in both environments.

My goal is to enable mobile objects between SL and .NET, and that means as much shared functionality as possible.

Yes, it is possible for someone to write some SL-only or .NET-only code in there, but the dual-project with linked files technique tends to catch that immediately when you build the solution. And if you stick with 'standard' CSLA property declarations and other techniques this is not likely to start with.

The only place you can get into trouble is with business or validation rules that interact with the data portal. This is because the SL data portal is only asynchronous, and that means this type of validation rule must be async too.

But we've added an async data portal and async validation rules to CSLA .NET too, so even that code will be common between the two environments.

In the end, only your constructor, factory methods and data access code are different between the two environments - which loops us back to the #if vs partial class question.

And even there, either technique works great. We're using some of each in testing (got to make sure). But there'll be actual samples in the near future, and they need to be consistent - one way or the other.

---

Rocky

I already have "too many files" in my app.

I have a code gen layer and then a layer of derived classes with a possible 3rd layer of more derived classes. If I have to triple each of them in order to support Silverlight, that could get out of hand. So I am leaning toward the compiler directives and keeping things in their proper regions of the BO.

If I only had a single set of BOs then I would definitely prefer partial classes but I don't so I won't.

Joe