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.
Related
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_
There seems to have a buzz around the Lightswitch application framework.
Reading some posts/forums/articles and listening to a video provdided some answers, but raised some others.
Extensibility?
Is there several hooks to override or extend features?
Modularity? Can MEF/Prism be integrated? Is there a concept of dynamic modules that can be loaded at runtime?
Localizable? Any special features about localization in different languages?
Versionnable? Any concept of version so simultaneous version can co-exist?
Abstraction? The connection to data source can be abstracted and replaced?
Testability? Are the different components unit testable in an automated way? Easy or difficult to achieve?
Cross-cutting / NFR ? Any hooks so we can plug NFR code? (logging, caching, audit, secuity )
Is this a solid framework to build some PAAS application over?
Let me give you my 2 cents based on an eval I just did:
Extensibility
You can of course add custom controls and apparently there will be a published extensability API.
Modularity
No. Lightswitch is not a code generator, it abstracts out implementation of the UI.
Localizable
Did not see anything, but I imagine this will occur in stages.
Versionnable?
You could TFS the Lightswitch project, but if you mean versioning from an execution standpoint ... it's as simple as deploying a new version of the app to the server. The client will check for updates on run and install as necessary from what I understand.
Abstraction
Yes, if you abstract it at the WCF RIA Services layer which is very easy to do.
Testability
Business rules can be implemented at the RIA Services layer so testing there should be a snap, but if you rely heavily on rules driven through the UI you will have to use another UI-based testing tool.
Cross-cutting / NFR
If you focus on getting the RIA Services tier of the app to be the central location for business rules and let the UI just focus on user experience you won't run into much overlap. I think Lightswitch is a good client for many solutions, but the core power of it is using it as a client for RIA Services which itself is not dependent on Lightswitch by any stretch.
I hope I at least provided some useful insight.
Extensibility? When the built-in LS controls don't allow you to do what you need, you can use just about any Silverlight control (including 3rd party controls), or create your own custom Silverlight controls. There is a little more work to do than using LS controls, because the LS controls have some extra "smarts" built into them, so you can just drop them on a screen, bind, & use them. There are also extensibility points built into the framework that allows you to create your own "extensions" (shells, controls, themes etc).
Modularity? LS already uses MEF under the covers, so it's quite possible that it may be able to be leveraged further in the future. LS does generate code, but for itself, not for external consumption. There is an excellent article, however, by Microsoft's Eric Erhardt
http://blogs.msdn.com/b/lightswitch/archive/2011/04/08/how-do-i-display-a-chart-built-on-aggregated-data-eric-erhardt.aspx
that shows how to reuse the data model that LS constructs (in Eric's case, he uses it to create a RIA service that aggregates data for presentation in a chart control).
Localizable? I don't believe there are currently any built-in localisation features.
Versionable? For a web-based app, if the data schema didn't change, I don't see why you couldn't publish separate versions, but desktop (OOB) apps are click-once apps & are therefore governed by that technology.
Abstraction? If you were to create a RIA service for your data source, you could abstract away the implementation details.
Testability? Unfortunately, V1 was not written with "testability" in mind. If you extract out your business logic into Silverlight class libraries (for use on the client, or full .NET class libraries for use on the server), you can unit test that logic, but the code that you write in an LS application itself is not really unit-testable at this point in time.
I have a Silverlight application that uses WCF RIA Services. I'd like to be able to switch the datasource to a local store (for example, SQLite) for demo or UI testing purposes.
At which layer should I refactor my code to allow to do this? Is there a way to do this without repeating functionality already present in WCF RIA Services classes (DomainClient, Entity, etc.), or should I create the switch much higher in the abstraction and bypass all of these classes altogether?
Thanks.
The DomainClient is the hook the framework provided for implementing this kind of switch. However, I don't think I've heard of anybody taking that approach. Instead, the split is often made at the Service layer of applications designed using the MVVM pattern (discussed in this video http://channel9.msdn.com/Series/Silverlight-Firestarter/Silverlight-Firestarter-2010-Session-4-MVVM-Why-and-How-Tips-and-Patterns-using-MVVM-and-Service-Pat).
Also, you might find this thread interesting as it discusses some existing patterns that have been used to persist data to the Silverlight isolated store.
http://forums.silverlight.net/forums/p/219768/524983.aspx#524983
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.
I'm just introducing myself to the basic differences between Silverlight 3 and it's predecessor. Looking at Domain Service Class within RIA services, the execution seems quite a bit simplified. Can someone explain the basic differences between this and Windows Communication Foundation?
Does the Domain Service Class employ WCF or some other services framework in the background, or is this new from the ground up?
I recommend you read this blog article which mentions that:
Our thinking on the RIA Services work really grow out of the LINQ project a few years ago. LINQ integrates query semantics into the languages (C#, VB, etc) providing a common abstraction for working with data; whether that data is in memory CLR objects, XML, relational data, or anything else. With RIA Services we are extending this pattern by offering a prescriptive model for exposing your domain logic over LINQ. We think of domain logic as that part of your application that is very specific to your domain – that is the particular business problem you are solving.
So it is to 'domain logic' what LINQ is to data, whereas WCF is essentially just a service provider.
In traditional N-Tier development this means that:
...you should think of RIA services as a more perceptive layer on top of ADO.NET Data Services and WCF... We also expect to eventually provide full access to all the power and flexibility from the underlying WCF services such as highly optimized binary serialization.
Or you also have the option to use the new "RIA Services pattern" to:
...build ASP.NET applications easily while taking advantage of all the built in features of RIA Services such as data validation, authorization, etc. In the March preview, we are offering a asp:DomainDataSource control that enables very easy ASP.NET WebForms access to your domain logic. Building on top of that is a future version of ASP.NET Dynamic Data that makes it very easy to generate common, standard UI based on your domain logic.
This essential means that the RIA Services can either:
Sit on top of WCF (essentially wrapping the WCF services for the Client App to consume).
Replace the WCF layer with RIA Services using alternatice data source (eg. ADO.NET Entity Data Model/Entity Framework as per Building A Data-Driven Expense App with Silverlight 3)
It is also worth checking out Mix09: Building Amazing Business Applications with Silverlight 3 for another example.
As i'm writing this i've just discovered Microsoft's .NET RIA Services Overview which looks like it explains a lot of the rational behind RIA Services (and probably a bit clearer than some of the above :)
We use a combination of both. WCF for bulky data that works better with binary serialization and RIA for CRUD entities because the code is so much faster to write and maintain. If RIA supported binary we would use it instead of WCF, but I am pretty sure it does not in the current release version.
WCF has much more options to debug as in RIA. The domain datasource is easier to set up but more difficult to figure out mistakes.
In much cases WCF will use for making an interoperability communication system which desolute older WSDL with WSSE header security.