It's my first question on SO. I know that there were many topics on Silverlight and architecture but didn't find answers that satisfies me. I'm ASP.NET MVC developer and are used to work on architectures built with the best practices (loose coupling with DI, etc.)
Now I'm faced to the new Silverlight 4 project and would like to be sure I'm doing the best choices as I'm not experienced. Main features required by the applications are as follows :
use existing SQL Server Database but with possibility to move to the cloud.
using EF4 for the data acess with SQL Server.
exitensibility : adding new modules without changing the main host.
loose coupling.
I was looking at different webcasts (Taulty, etc.), blogs about Silverlight and came up with the following architecture.
EF 4 for data access (as specified with the requirements)
WCF RIA Services for mid-tiers controling access to data for queries and enabling end-to-end support for data validation, authentication and roles.
MEF Support for enabling modules.
Unity 2.0 for DI.
The problem is that I don't know how to define a reliable architecture where all these elements play well together. Should I use a framework instead like Prism or Caliburn? But for now I'm not sure what scenarios they support.
What's the best usages for Unity in Silverlight ? I used to use IoC in ASP.NET MVC for loos coupling and other things like interception for audit logging. It seems that for Silverlight Unity doesn't support Interception. I would like to use it to enable loose coupling and to enable to move to the cloud if needed.
Thanks in advance for your help.
Best practice in Silverlight is actually (IMO) a bit a myth. By definition "Best Practice" refers to practices that generate the best results overall (quick to market, fast iteration of versions, low bug count, etc). However Silverlight 4 isn't even in production yet so its not actually possible to pin point what ultimately has turned out to be "Best Practice.
On top of that Silverlight itself and the technologies that surround it have been very fluid and and are very new. With that in mind here is my 2 pence.
EF and WCF RIA Services are most definitely going to figure in your architecture if you are build a LOB app. (Although NHibernate instead of EF may be worth a look, I tend to bias to MS components unless there is something else that knocks it out of the park).
MEF is most definitely worth further investigation if you are into DI. Its this area which is most in flux right now. I wouldn't be surprised to see Unity and Prism evolve to make greater use of MEF to deliver their various patterns. MEF is particularly good the loose coupling of which you speak.
Related
We're starting to develop a new Silverlight LOB application where the DataAccess will not be based on EF, rather our own DAL code (for legacy and other not related reasons).
We are currently debating whether to use RIA Services or simple WCF Services as the Silverlight's facade layer.
The options:
RIA Services and generated code: RIA Services will automagically create proxy classes of our Domain Model and DomainServices in our Silverlight project.
This will mean that our services will need to inherit from the DomainService class, and will require much work and workarounds to allow our custom model to be serialized normally (since we dont use EF)
WCF And shared libraries: We'll create a DomainModel library that will be shared between both Silverlight and our server code (as offered here) giving us more control as to how our domain classes look, and how they are seen on Silverlight, and our services would remain clean as WCF doesnt require us to use any base class and give us much more power over how our services are exposed.
So the question is - given that we dont use EF, what are the pro's to RIA Services, and what are the con's of using WCF and shared domain?
I have reasonable real-life experience with both technologies.
The main pros and cons in my perspective:
RIA Services
Pro: Development is (much) faster, even without using entity framework. You can create ViewModels, maybe mapping them with AutoMapper, and specify the attributes needed for validation / data entry / relationships. This is good practice even when using entity framework.
Con: A lot of overhead.
Con: Performance degrades when sending larger amounts of data (something like > 100 objects)
WCF and Shared Libraries
Pro: Performance is relatively excellent
Con: Development time / maintainability is not as good as RIA Services.
Con: Cannot use databinding as well without DomainDataSource (even when using MVVM).
Update
For the data-binding part: RIA Services allows for the DomainDataSource control in Silverlight. This enables easy (async) loading with bindable properties for its state (Busy etc.) which makes it easy to do loading animations and general improvements on user experience. This can of course be done without this control, but it helps.
For the RIA services performance, I cannot seem to find the example (someone here said they lost a few months of development time rewriting domain services to conventional WCF services because of the response time that could not be met).
One more note about a Silverlight (Business Application): try zooming your browser in to 110% or 90%, some arbitrary percentage. The fonts / components will get blurred because of way the rendering works. I have confirmed this on multiple machines/configurations and have not found a fix / work around for this. Snapping to device pixels does not help here at all.
Also before you make a decision, it's probably smart to also consider MVC3, with JQuery and HTML5 as an option for your solution. The HTML layout system might not be as good as Silverlight, but there are advantages like cross platform and mobile support.
I'm building a silverlight line of business application in silverlight 4 using RIA services currently and i'm finding RIA services to be more and more of a pain everyday..
A lot of the database interaction in this application doesn't follow the usual CRUD pattern and some of the data just doesn't "fit" with the RIA services style of doing things..
Even more importantly it doesn't fit the way my brain thinks about web services!
(I think that abstraction often gets in the way of the business problem you're trying to solve)
It's got to a point where a scary chunk of the code base is workarounds for the object context and spoofing ID's to create some kind of unique key etc..
I'd also like to swap out entity framework for rob conery's massive (he thinks the same way as me about abstraction, dynamic typing etc..)
Are there any alternatives which work using dynamic typing and JSON?
If not I may have to roll my own!
Have you looked at WCF Data Services?
http://msdn.microsoft.com/en-us/data/bb931106.aspx
You might also find that WCF Web APIs suits you better.
http://codebetter.com/glennblock/2010/11/01/wcf-web-apis-http-your-way/#0_undefined,0_
I have been dabbling in WCF RIA with Silverlight for the past few weeks and I am finding it very difficult to generate well-designed software using it. My impression is that it's a tool that's best used for "rapid application development", prototyping and fancy-looking demonstrations.
As an example, to make the most of RIA I find you pretty much have to take a dependency on your data model from end to end. The best-sounding features of WCF RIA (like end-to-end validation and EF integration) require you to present your Entity Framework data model pretty much as-is, all the way down into your presentation layer. This precludes designing your software using a Service Layer pattern, data mappers or DTO's. I also find myself struggling (so far to no avail) to create an application with a true Domain Model due to limitations in EF.
The code generation stuff is nice and I could see it saving me time, except that it doesn't support such basic scenarios as many-to-many relationships. This causes me to have to expose even more of my database implementation details through EF by exposing the intermediate foreign key table.
On top of these issues, WCF RIA is notoriously almost impossible to test. DomainContext classes are not hidden behind interfaces and doing so is extremely difficult due to change tracking and other subtleties. In every single case I have seen in the wild, ViewModels end up taking direct dependencies on the DomainContext implementation. Even when this dependency is constructor-injected it's meaningless because it can't reasonably be mocked.
So I guess my question is two-fold: Does WCF RIA enforce bad design? If so, are there any reasonable workarounds that don't end up with me losing most of the advantages of the platform? And if not, can someone point me to some literature that shows how to generate good designs based on tried-and-true patterns using WCF RIA?
You might re-phrase the question as "Can I have my cake and eat it?".
Having been coding for some 30+ years I have seen this cycle many times:-
3rd Generation Language is too flexiable we are repeating ourselves doing the same things over. What we need is 4th generation language or framework the cuts out all this repeatition.
4th Generation Language or framework is too restrictive it forces me to find ugly workarounds and "enforces bad design" in my specific project. What we need is a more flexiable lower level language that lets us do exactly what we want.
Yet another 3rd Generation Language is too flexiable .... cycle repeats.
Tools such as RIA, Lightswitch, WebMatrix etc are in the 4th Generation camp. They by design enforce a specific way to doing certain tasks in order to eliminate repeation and to allow developers bang out working stuff quickly. Developers trade ideal design for speed of developement. This tradeoff is as old computing itself.
So to answer your question, no you can't have your cake and eat it. You either do things their way and use the RIA WCF service or you do things your way and create your own
WCF services. There is some middle ground (as always) where you can use some RIA WCF then jump through hoops making it do what you want.
BTW, EF does offer considerable abstraction (albeit with a lot effort) between the model it ends up presenting and your actual Database schema. It does for example allow you to present a many-to-many relationship without an intermediatory class.
The answer to this question is "No". It doesn't enforce "bad design". It's just a specific tool in your toolbox and it's designed to solve a particular problem. You sound like someone who is trying to take a hammer and use it to drill a hole, and saying, "Why doesn't this thing make a nice hole in my wall?" Ummm.. Because it's a hammer man. It's designed for a different job...
A lot of our skills as developers is in figuring out the right tool to use for the job. Silverlight and RIA have their uses, but they are not a magic silver bullet.
I think you're looking at the technology with the wrong goals in mind. And I say this as a guy who is a big fan of TDD, MVC, etc. I've written my share of apps that use DTO's, Repositories, layers, abstractions, etc... I've also written quite a bit of Silverlight and RIA in the past few months.
Anthony said it well: Silverlight and RIA are designed to "eliminate repeation and to allow developers bang out working stuff quickly." I don't think Silverlight and RIA are desgined for giant enterprise apps with loads of business logic tucked into the VM - something where you need unit testing and TDD to drive the process... This is the wrong tool for THAT job.
I decided to look at some of my ViewModels in some recent projects in Silverlight. Here's what I found: Everything I'm doing in the VM is pretty much delegating to something Silverlight already does for me: databinding, observing property changes, querying data contexts, saving changes to a data context, validating entities and notifying the GUI, etc.
Silverlight and RIA already do these tasks for me. I am just delegating calls! If I were to write a unit test, I'd be testing Silverlight and RIA - not my domain logic! I don't need to test the framework - I assume MS knows what they're doing.
If you have enough complexity to warrant DTO's, data mappers, service layers, etc... Then you probably need to think about something other than Silverlight and RIA. Know what I'm saying?
The right tool for the job man. Choose the right tools.
I know there are other issues involved in any decission when beginning a large project, but my experience in the past has been with SL web based apps (w/ entity framework) where I have found wcf ria services such a time saver, I am wondering what people think about the reasons one might remain with wpf for desktop apps where so much more effort must be expended to match what the ria services provide in SL. This project is definitely a data-centric business app.
Any and all oversvations and experiences would be most welcome.
Thanks,
Steve
I may have some insight on your situation, since I am faced with making the same decision right now. I wrote up a blog post about my experience here:
http://samuelmueller.com/2010/11/wpf-4-vs-silverlight-4-which-do-you-choose
To summarize, WPF has one very big advantage over silverlight, especially with data-centric apps:
Performance.
With that being said, the list of negatives is quite daunting, and really makes WPF a hard sell over Silverlight:
No support for WCF RIA Services, even with SP1
Sub-par validation support, with INofityDataErrorInfo missing
The WPF toolkit has been practically abandoned, whilst Silverlight toolkit and theming are very much active.
No Fluid UI
If you can live with the performance, it seems like Silverlight is the more productive and compelling choice, at least until MS makes some effort into leveling the two platforms.
The thing is, Microsoft seemed to have developped WPF at the beginning, but failed to really keep it fresh. On the other hand, they are working on improving Silverlight, releasing new version almost every years.
I still like WPF over typical windows forms and find that not having RIA services isn't much of a problem since you can still access databases the way I am used in normal Windows Form.
I'm looking at Silverlight architectures and RIA Services looks interesting, but I am a bit concerned about its prelease status and how the feature set will change.
We need our client app to be as responsive as possible over a slow network link, so a high priority is a solid sync system for pushing model state changes from the client back to the server. Will RIA Services help us in this regard or will I have to roll my own logic to do this ? Are there any other frameworks that can assist with this? Is the feature set involved in these requirements liable to change much in the next couple of months?
If it makes any difference, our frontend is 100% Silverlight, so we dont need to worry about exposing SOAP APIs from the server or anything like that. It appears to me that RIA so far is a bit more mature for Silverlight use. Is this correct?
I am using SL 3, .NET RIA and EF. Still trying to figure out how to load, and update data effectively and best in performance. Little information that I have so far how to improve the performance issue that I face. Still need more time to get these frameworks to be mature. Hopefully, there are more resources and insight in the near future.
My take is if you are handling very light data application, silverlight can be a good choice. Once you have loaded the application in to your machine, it is like loading application within your box.
I would look into some of the ORM's / IoC Frameworks which help create a separation of interests. A couple examples are Castle Windsor IoC, they have a sample Silverlight 4 application that utilizes the Castle Windsor Framework. Another common ORM for Silverlight is
BL Toolkit. These have been around for a while in the Java arena but are newer in the .NET area. They basically help to move the complexities of the relational data model out of the UI code and delegate it to the Framework.