Vibrant discussion about CSLA .NET and using the framework to build great business applications.
are there any plans for developing the core in csla using the new Portable Class Library to simplify the deployment to different platforms? Then there could be a csla.winrt.dll targetting winrt, csla.web.mvp.dll targetting web forms mvp, csla.web.mvc.dll targetting aso.net mvc and so on.
Anders Sidvall, System Developer from Sweden
I've put a lot of thought into this.
The problem is that the platforms are so different, but that may be changing.
Right now, we have quite a lot of code that is optimized for full .NET vs SL/WP7 vs WinRT. All that specific code could be refactored into external assemblies, but that would mean that you'd always have to reference two assemblies to use CSLA - the portable Csla.dll, and the platform-specific assembly that is required for each platform.
That would be silly, as it would gain nothing. In fact, it would be worse than today, because you'd need to do two references instead of one, and it would still be platform-specific.
However, this appears to be changing. Specifically, Microsoft appears to be settling on WinRT for all client platforms (Win8, WP8, rumors of xbox).
As a result, I think it is quite realistic to think that the future will be simpler - possibly enabling the use of portable libraries without the downsides of today.
Maybe it will be in the future, but not for Win8 according to this:
A common core across Windows Phone and Windows 8 also should be good
news for developers. It would seem now you could write once and really
have it run anywhere? But the reality is a bit more complicated.
Developers cannot take their Windows app binaries and just run them
on Windows Phone 8. However, there is a high degree of code reuse
possible, Sullivan said.
Microsoft execs have said repeatedly that existing Windows Phone 7 apps will run on Windows Phone 8. The two phone platforms are binary compatible, Sullivan reiterated.
According to Microsoft officials, the developer platform for Windows
Phone 8, which are powered by ARM processors, and Windows RT — the
version of Windows that runs on ARM processors — is “similar.” But it’s
not exactly the same.
“We don’t have the unified runtimes and APIs (application programming
interfaces) exposed,” Sullivan acknowledged. “But the tools are the
Jonny Bekkum, Norway
Just to follow up with a concrete example for anyone reading this thread in the future.
Everywhere we currently use #if statements in the CSLA codebase must be normalized to not use that technique. So the public API can't be conditional at all - it must be universal.
Take the data portal then, which has (now) three types of API: synchronous, async with events, async with async/await.
We could create our own Task<T> type to 'fake out' WP7 into compiling the methods, but that'd be ugly.
In non-.NET platforms we'd have to throw a runtime exception if the sync methods were called - they'd be just noise to all other platforms, but everyone would have to live with that noise because we couldn't selectively hide invalid options from the developer/compiler.
There are other, deeper, examples of issues like this - but the data portal API issue is clear an obvious.
It is possible to create interfaces in the portable class library and allow each platform to supply their actual impementation using resources that are not available in the portable runtime. This is how the WordFeud game was ported to Metro in a rather short time.
Jonas Follesø had a talk on this at NDC 2012, available online here: http://vimeo.com/43548884
This might be a way to go in order to avoid the #if statements where the implementation is different for each platform. It would however require us to (probably) use MEF to deliver the extensions inside CSLA as MEF is supported/part of Portable Class Libraries.
AsyncBridge https://github.com/OmerMor/AsyncBridge adds support for async/await in Portable Class Libraries (which the Async Targeting Pack does NOT support). Also available on NuGet: https://nuget.org/packages/AsyncBridge