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.
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.
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 an asp.net web app which holds its data in an sql server 08 r2 db.
I have a silverlight admin interface on the same web app, and I will have a win forms app which will need to add/retrieve data from the sql db. Is there a way I can use linq in both clients?
I mean something like linq2twitter, where in the silverlight or in winforms app I can use linq to query and update the data.
Currently Im thinking of just using web services, but the data objects are complicated and they're connected to so many other data objects, it would be very convenient to work with them in linq, especially because the asp.net app itself uses a linq data context for its operations. Is there a way to expose this context over http or something?
Thanks
I think you probably want to look at WCF Data Services - which does pretty much exactly what you suggest i.e. it exposes a data context via web services (see also OData) and provides tools to consume and work with same via Linq
I tried WCF Data Services, its freaking amazing but it was a little hard to get up to speed with it, and difficult to diagnose what went wrong where, just for anyone else in my position here is what I did:
I watched this really fun scott hanselman video on OData
Landed on this msdn page after 1 hour of meandering. (Note all the snags like loading related entities, also, there is a list of unsupported linq operations on wcf ds)
Went crazy looking for some examples.
Tried my own stuff with lots of problems--> Got fiddler and then fixed all of them =)
Hope that helps!
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.
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.