What's the best way (e.g. framework) to access a database using Silverlight?
Using WCF RIA services. This allows you to access your Data using RIA Service Layer that can also have some business logic in it. For more details visit this article on RIA:
http://msdn.microsoft.com/en-us/library/ee707344%28VS.91%29.aspx
Ragards.
I guess it is difficult to define "best". I think is more a personal preference. I have used a webservice and linq2Sql in the past.
I have used this (http://www.silverlightshow.net/items/Silverlight-2-Simple-Editing-of-Web-Service-Data-in-a-DataGrid.aspx) tutorial as a base.
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_
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Sorry in advance for the wall of text!
Scenario:
We're looking at what technology to choose for a LOB app that needs to support a "stand-alone" model (frontend + backend running on desktop machine), but also local server mode (backend installed on a local server), as well as Software as a Service via the internet (backend installed on a hosted server).
We want to minimize the development work, which is why we chose the Silverlight frontend. We intend to re-use the same codebase for all 3 models.
The LOB app is heavy on data inputs and will do some math work on the backend. We will have a large amount of views. And we will have a database with 80+ tables. We currently have our own DAL that enables us to use MSSQL, MySQL and Oracle as DBMS's.
The current vision is to use an Agile TDD Silverlight 4.0 MVVM app as frontend in C# with the Caliburn framework. And to have a WCF (RIA?) service as backend (Non Silverlight, plain .NET 4.0). This fits the different models well, since it's just a matter of where the backend is installed. For the SAAS model, we have a server on the internet where the backend could reside.
Questions:
Does this sound viable at all, or is it whishfull thinking that we could have the same codebase for the different models?
With regards to the backend, we are looking into WCF RIA Services, but would like to have "Message Security", which does not seem to be possible in the Silverlight implementation of WCF. Is WCF RIA a valid choice? Or is plain WCF "better" with regards to security in any way?
With regards to the different DBMS's we need to support. Is this viable to do with WCF RIA Services? Or are we better off creating our own BLL/DAL and expose that ourselves via plain WCF?
Does anyone have experience with a multiple DBMS setup using no inline SQL, just Stored Procedures? The original app is heavy on inline SQL, but we are wondering how maintainable this app would be with only Stored Procedures in the different DBMS's.
Final question, with regards to MVVM and security, we would like to "hide" as much of our logic in the backend for security/code protection reasons. What would be a logic thing to do for this? We need to do TDD, so we need to be able to mock-out the Model, which means it needs to be available in the frontend. But we need all the logic to be in the backend. Should we just use a "wrapper" in the frontend that "links" the "real model" in the backend? Kind of a dummy model that fits 1-on-1 with the backend model. Or is there a "better" way to do this?
Thanks in advance for any help you can give us in any of these subjects!
Huron.
It should be viable, but you're gonna have to really think the communication model through. The SaaS scenario is the most restrictive and security sensitive, so you should start from there and scale back to the all-local setup.
I'd advise against RIA services. As often is the case with MS it's nice for simple stuff, but you'll soon enough run into it's restrictions and then curse it. See here for how to do Message Security in SL.
As in Question 2: I wouldn't go with RIA, but even if you do, you can use Entity Framework and keep it DBMS agnostic.
I for one am a fan of stored procedures. Yes, it creates multiple points of deployment (and the inherent risk of version differences), but I always say "keep SQL in SQL".
Unfortunately what you're describing is a common issue in TDD of interfacing systems. I'd use a mockup client to test the server and then use the real server to test the client.
Here is what we've ended up choosing for our LOB - local/client-server/saas app :
This turned out to be extremely viable. We have very few exceptions, most of the codebase is exactly the same, for local, client server and saas.
We decided not to go with WCF RIA, but to use regular WCF Calls, we are using "TransportWithMessageCredential" to secure the communication.
We are using Entity Framework for exposing the database to our backend application. There we have our domain layer and our custom "Entity" classes, which we fill based on the EntityFramework Classes we get.
Since we are using Entity Framework, our SQL statements are all completely gone. We are using Linq to select what we want. So far this is working great. So no more inline SQL. And by introducing separate layers (Entity Framework -> Context class -> Mapper Class -> Entity Class) we have a high maintainability.
We have dumbed-down the frontend as much as possible. The ViewModels we have there are strictly used for filling all the bound-properties so the View has data to work with. All the decissions with regards to what data or what is possible are being done in the backend. The entire flow of the application is run by a Manager class in the backend which uses a WCF Duplex connection to tell the frontend what to do.
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
I passed the hello world phase in the Silverlight world but I found out that ADO.NET is not part of the party. :_(
I'd like to know what is the easiest method to retrieve tables\rows\single value from SQL Server.
(At the moment I have a very small DB, so simplicity is more important than complicated smart solutions that can handle large amount of data.)
I what to be able to send a query like:
SELECT * FROM a JOIN b....
I found this article which I'm learning at the moment, yet I'd like to know if there are other ways to access the DB.
Thanks
Asaf
Other way is to use WCF RIA service.
You can't access a database directly from a Silverlight application.
The only way is to use some service.
Here you can learn how to do that with RIA service.
As suggested above, use WCF. This means setting up a WCF service on the webserve which does all the SQL magic. You may want to look at LINQ2SQL (obsolete) or Enterprise Framework for accessing database in this service. In Silverlight you just connect to the WCF service and it will be like magic, especially if you use LINQ.
Remember that you must access the same server your Silverlight app was downloaded from. If not there are special rules that apply.
For binding the data and interface Silverlight (and WPF) supports the MVVM model. This model really simplifies GUI implementation and makes it very easy to maintain the code.
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.