Hi,
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.
Regards
Anders Sidwall
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 same.”
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.
Hi,
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
So:
I don't see the issue here, you could separate everything in differenct libraries. This way you could separate for instance the BusinessBase, BusinessIdentity and other classes into some kind of Csla.Domain library and keep the DataPortals in there respectivly own classes.
Why not use conventions to retrieve the actual dataportal implementation (like Csla.DataPortal.dll). This must only be done at the first call to the dataportal and even open doors to the creation of additional DataPortal implementations in the future like IsolatedStorageDataPortal, AzureDataPortal and others.
maybe it's time to redesign csla from scratch to implement patterns correctly instead of just patching up old code (if I go through the source I see a lot of violations like multiple classes in a single file, inconsistent namespaces, ...) This would be a great opportunity to get rid of these as well 
)
Copyright (c) Marimer LLC