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
Related
I am planning an application which will have a web based component and a desktop client component. Basically I am planning to create the web based component using ASP.NET MVC3 & Entity Framework as a normal data driven website, however I am also planning to create a desktop client that will extend the functionality of the website, this is new territory for me and I am somewhat confused. I know that the best way to create an application that needs to access a central database is using WCF, however I have not used WCF before but have heard that it easily integrated with Entity Framework.
So I know that what I want to do is certainly possible I am just looking for some guidance for how the seperate components of this application should glue together, etc should I be working with WCF and Entity Framework first? Or should I complete the web based componenet before working with WCF?
Thanks,
Alex.
There are lots of ways to do this and all these ways have different level of complexities. For example, you could just build your web-application using Entity Framework, in the same web-application you expose an OData service (WCF Data Service) which provides a RESTful service that your WPF app can use to access the database. This is fairly easy, since WCF Data Services work really nicely with Entity Framework. This is basically a two-minute job (if you are not doing anything fancy). Your WPF application then has basically the same type of access to the database as your web-application does. In it's default configuration the WCF Data Service simply exposes a EF ObjectContext and allows the same type of operations on it. I would recommond you try this out and see for yourself if it fits your requirements.
But, this approach is basically a shortcut to allow a desktop application access to your database. Which in most cases, is perfectly fine. If you do want to put some effort into it, you could model a service-layer which either uses a Entity Framework data source or a OData data source. From here on in, it's all about design patterns. Which comes at a cost; separation of layers is a hard thing to do, if you want to do it right. Given that the .NET world as somewhat changed to "get the job done", it's fine to put those bits together and get a running app in no time.
You should also consider that the MVVM in WPF and MVC in a web-application have fundamental differences; where a MVC app just pulls a "snapshot" out of a database, a WPF application might need more effort and asynchronous programming to feel natural.
I can provide you with some guidance for specific tasks, like how to decouple the WCF Data Service and Entity Framework, but from my experience, the overhead of "doing it right" is enormous. If you are comfortible without a service-layer you will have a lovely experience working with EF and OData.
It is better you start with the web component first integrated with wcf, you can use entity framework, but i would recommend using T-Sql itself if you have a data heavy DB and it gives you lot of options for performance.
I would recommend you build the application model using MVP pattern as it makes it easy to switch from a desktop to web application and also inline with your requirements of extending it.
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'm confused about the architectures which we can use to develop a business application with WPF 4.0 and EF 4.0 technologies.
My first choice was a traditional N-tier architecture contains: UI, Business Logic Layer & Data Access Layer with a disconnected behavior.
In this way I create 3 project for each layer and another project for my Entities/DTOs (Each layer is an assembly). Each layer references only to it's upper and lower layers (That is: UI can see the BLL but can't see the DAL). But all layers have access to the Entity/DTOs assembly for communication purposes.
The problem starts when I want to create a simple CRUD form with a DataGrid for example. The BLL disposes the DataContext of the DAL when returns an Entity/DTO, this is the reason that forced me to use STEs. But yet there are several problems. For example I should call "StartTracking" method for each entity returned from BLL to the UI. In short, I don't sure about this pattern reliability or I think I have to forget about automatic handled CRUD forms.
I use the repository model in my DAL layer but when I search about the repository pattern I find it different. It seems that it's not bad to reference to both of the DAL/Repository and the BLL/Services(Not WCF nor WebServices) layers from the UI and thus we can have a connected environment (Without using STEs).
I see an example in which we can get a person from repository but do something on it using BLL or services:
UI CODE:
var person = new PersonRepository().GetPerson(10);
Bll.Salary.PaySalary(person);
-or-
var person = new PersonRepository().GetPerson(10);
Bll.Person.MarkAsAbsent(person);
Or something like that...
With this pattern we can send the Entities/DTOs to the UI in a connected way while the DataContext is alive.
I don't know if I understand the way of using the repository pattern in big projects. I think it's not clear to naming the BLL or services classes and methods in this way. More over the developers might be confused about where to use the repository methods or BLL/service methods or about where to create the methods (in repositories or BLL/service).
I prefer the N-Tier architecture using a good approach to track the Entities/DTOs changes automatically like STEs.
Would you please recommend the best pattern in such situations or/and reference me to some good books or documents about that.
I put together a sample app that may help with some of your questions. You can review the presentation notes and the sample via my blog post here:
http://blog.alner.net/archive/0001/01/01/wpf_ef_4_sig_presentation_2010.aspx
The sample shows using STEs and includes some helpers to make the Entity Framework STEs work better in a desktop client app.
Repositories are there to hide the details of how you get the data. The idea is that you could swap the implementation of a repository from one that uses a local database, to one that uses a remote web service without the upper layers knowing about it.
Maybe the article Architecture for WPF applications is any help for you.
You might have a look at the BookLibrary sample application of the WPF Application Framework (WAF) as well. It shows a WPF MVVM application together with the Entity Framework applying the described architecture.
I'm starting to jump in to WP7 development and I have a few questions. My current background/experience is with ASP.NET. I'm new to Silverlight as a whole, so I have some questions regarding the architectural design of the application. I don't have experience with MVC, and it appears that Silverlight is based off of it. Is that true? To my original question:
Once the new developer tools come out, the app will have a SQL CE back end that, as a future release, will sync with SQL Azure. I'd also like to provide a web based application that performs the same functions, and interacts with the Azure database. I'm wondering how I should structure the app to minimize any code duplication.
I was thinking of using a generic n-tier architecture. UI > Business Layer > DAL (LinqToSql) > Sql. These classes could get re-used on the web too.
Silverlight is not really based on MVC. In fact, you can implement any architectural pattern as long as you fully understand its functionality. Most people prefer MVVM, which is similar to MVC, the only main difference is that the controller is replaced by the ViewModel that plays the role of an intermediary data link between the model and the view.
With the release of Mango, you will indeed have access to SQLCE. In your case, since you are planning on using specific interoperability layers, I would recommend building both applications in Silverlight with an intermediary web service that will communicate with the data storage (in your case it will be Azure). You win in two points:
You are using Silverlight, which means that you can use a similar codebase (with platform adjustments, of course) to deliver the same functionality.
The web service is app-independent. Therefore if you ever decide to build, let's say, an iOS application, you will be able to use the same communication layer without major changes.