I've come to the conclusion that I'll have a WPF and HTML 5 UI's for my next project and not a silverlight one.
I do however forsee a possible Windows 8 Metro UI down the road.
I'm not sure on the path to Metro and WinRT from CSLA 4.2 but does it require keeping the
#if !SILVERLIGHT
directives and coding?
I'd rather not write one line of code I don't need to.
I started my business object library with a few sample objects for testing purposes and dutifully inserted the code for Silverlight but now that I'm ready to get stuck in I can't tell if it's safe to completely disregard silverlight entirely considering Metro and anything else I'm not aware of that you guys might be.
Ditch the Silverlight support or keep it for some unanticipated reason?
I've wondered at similar subjects. I'll stick on WPF but shall my BOs provide async DataPortal behaviour?
Moreover, I don't think SL will support our business any better, easier than WPF (as we have some peripheral devices, easy printing of form requirements). On the mobile device market, our customer have an Mac or Android device, bat rarely a Microsoft. And today a mobile device doesn't support our customer without a mobile printer at hand ;-)
Therefore, my conclusion is keep going the WPF trail without overhead of possible SL / WinRT features.
But really important is a layered architecture and proper design, including the MVVM.
For the future I'm very interested in the on going development of CSLA, and following the new concepts.
I'll spend time and money if there's a concrete oppurtunity for our product in any technology. But now I want to keep it simple and clean.
You may want to readt through the blog posts I've been writing on Win8/WinRT (Metro) and how it appears to relate to .NET and SL.
http://www.lhotka.net/weblog/CategoryView,category,WinRT.aspx
In summary: the closest thing to WinRT today is Silverlight. This is primarily because:
WinRT is not the same as SL, but it is closer to SL than to .NET or WPF.
The CSLA 4.2 code in svn builds on WinRT. This was done by starting with the SL codebase, so the SILVERLIGHT compiler directive is defined. I did this, because otherwise I'd have had to re-apply all the SL code changes, and that would have been a waste of time.
I also define a WINRT compiler directive, because there are (quite a few) specific bits of framework code for WINRT. But at least simple business classes build for SL just work in WinRT right now, so that's quite exciting! :)
Good to know and I was afraid of that! <grin> I think I'm going to apply the YAGNI principle here and skip all the silverlight stuff and add it later for Metro if required.
Cheers!
The big thing is the async server access. CSLA shields you from almost everything else, but there's such a deep difference between sync and async data portal (and therefore some business rules) that it just can't be abstracted.
fwiw, we're clearly looking at a future where many/most things are async. Learn and use it now, or learn and use it in the future, but the async issues look unavoidable.
Also fwiw, I build all my WPF apps using the async data portal anyway, because I don't want the UI to lock up every time the app talks to the server. So my personal recommendation is to use the async data portal, even if you don't bother with any #if SILVERLIGHT directives.
In fact, if you only support the async data portal, and use a pluggable DAL, your code will almost work on SL without any directives.
Thank you!
In fact, if you only support the async data portal, and use a pluggable DAL, your code will almost work on SL without any directives.
I felt puzzled. On second thoughts...
If I don't use any SQL stuff, the code will build as a Silverlight project. WIth a plugable DAL that uses DTOs, I don't need to reference both System.Data and System.Data.SqlClient..
Although the DAL plugs an assembly that references both those namespaces, it does happen on the server side. And the server isn't running Silverlight.
Nice catch and a strong argument in favour of using DTOs on the DAL.
OK, if using the async approach shall be the easiest regarding future changes, which kind of mechanism would you recommend?
If I remember correctly one of the Rocky's blog entry, he has stated that CSLA needs the support / work with different meachanims. Know I wonder which would be the best regarding an "uncertain" future (and currently using WPF)?
My suggestion is simple: use the async data portal.
Today the async data portal uses a callback technique to indicate completion.
In .NET 4.5 it will support the new async/await keywords too. My plan is that CSLA 4.5 will have new async data portal methods that allow you to use async/await.
The challenge, of course, is that nothing prior to .NET 4.5 officially supports this new model. And for a period of months or years, Silverlight and WP7 won't support it, even while .NET 4.5 is available. So CSLA will maintain the callback scheme too, so it remains possible to write one set of business classes that work across these different platforms.
If you want to wait for async/await, that's fine, but that functionality won't be available until sometime next year when .NET 4.5 comes out.
Copyright (c) Marimer LLC