I've just found out about Visual Studio LightSwitch, Microsoft's new Silverlight-centric RAD tool.
Does this occupy the same space as WCF RIA Services?
Is WCF RIA effectively dead?
I've been doing some reading, and it seems that LightSwitch actually builds on top of RIA. I saw the following in a review in The Register -
Database connectivity and user
authentication in LightSwitch uses WCF
RIA Services, Microsoft's web service
framework for Silverlight, though
developers are shielded from the
details. This means there is a middle
tier running on Microsoft's IIS web
server.
Lightswitch does not make RIA Services obsolute. They are both valuable but are aimed at different audiences. RIA Services is aimed at professional programmers that want a high degree of control. Lightswitch is aimed at non-professional programmers. You can think of it as a Microsoft Access for building Silverlight applications.
I don't know where you found that quote "LightSwitch is targeted at professional developers and power users looking to create custom LOB applications", but that's NOT what LightSwitch was intended for at all. Power users, yes, professional developers, no.
LightSwitch is targeted at the non-developer, the type of user who creates "departmental" apps, who would perhaps currently use Excel, or Access. Though a number of professional developers (myself included) have recognised that LS is a fantastic tool for us to use as well, we were NOT the target audience at all.
As for RIA services being dead? Not at all! In fact RIA services is one of the main ways of accessing data that LS currently has trouble with (aggregation, projected entities etc). Using RIA services in LightSwitch is VERY easy. We're hoping, with the interest expressed by developers, that things will improve in that direction in future versions.
I agree with Phil, I tend to think of LS as Access.NET, even though it's far more than just that. Think of "forms over data" with all the latest technologies. Silverlight (both in browser & desktop), MEF, Entity Framework, RIA services etc.
Yann
Related
I am new to asp.net and ado.net. I must to develop a content management system with .net and I wonder which option is right for me, disconnected or connected architecture for web?
I dont understand why I should use dataset on online applications.
It sounds like you are getting started with ASP.NET so depending on which technology you prefer (MVC or Web Forms) either of these two tutorials provided by Microsoft will be of great help on general data access.
MVC: http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc
Web Forms: http://www.asp.net/web-forms/tutorials/data-access
I am going to create a basic "CRUD" application that will "live" inside Sharepoint 2010. The data will be hosted on a SQL 2008 R2 Server.
Basically, there will be a few "Add" forms, some Queries and some Reporting (SSRS).
Honestly, the application doesn't really even need Sharepoint, but we are trying to get as many of these applications hosted inside Sharepoint as possible. (The application is currently a Microsoft Access application.)
I have experience creating these types of applications (ASP .Net) and have recently been using the Entity Framework. Generally, I design my Data Layer in a seperate Visual Studio Project (using EF) and then extendthe partial classes it creates and/or sometimes create another POCO layer to access the data (depending on how much "business logic" there is).
Anyway, the question I have is:
If I create a (Visual Studio) Solution (I know I have to target .Net 3.5, since because SP doesn't support 4.0 yet), can I use my usual "layered" design and create a seperate project (assembly) that conaints all of my Data Access (Entity Framework) and then have a seperate Project that contains all of the Visual Web Parts (that we design the Data Entry Forms in)? Will this work? Will I be able to call the exposed methods from the (EF) DAL from within the Visual Web Parts (after I deploy my solution to the SP Server)? Will I have to do anything "special" or will both projects get packaged up into a (what is it) "wsp" file and get deployed to SP? (Or, will I have to manually get my DAL Assembly added to the GAC, etc.)
Any examples or tutorials would be a big help to me too.
Also, if you think I am going about this all wrong, I am also interested in knowing how you would create a similar appliation. Is there a better way to do this? (I know I could create a BDC Model and access our SQL data via a Sharepoint List using the External Content Type. Although, for some reason it just seems like that isn't the "right path" for this particular application... I can't put my finger on it, but I am leaning toward just creating a "traditional" ASP .Net app that just uses SharePoint as its "hosting web server".)
Thanks!
Shayne
Can you do it: yes. Should you do it: probably not.
You hit it on the head. You are creating and ASP.NET application, not a SharePoint application.
Anyway, assuming you are going to have to proceed in this manner, here's my advice.
Build the presentation layer (web parts, application pages) using the SharePoint project template and SharePoint project items. This project can reference the assemblies that implement the remaining layers of your application. Visual Studio will then prepare a Solution Package (WSP) that can be used in testing and deployed to production servers.
You should do everything you can to make your application "fit" into SharePoint. It should use the same UI metaphors, respect branding, and so on. Nothing is more jarring to a user then to have pages and web parts that look and behave total different to SharePoint in the middle of a SharePoint site.
If you have the full version of sharepoint you can use Access Services, which will convert your Access application to a web app, just run the wizard
see this video for details: http://channel9.msdn.com/Shows/Access/Microsoft-Access-2010-Demo
Why do people call RIA services a black magic? What kind of black magic do they refer to ? Also, i have seen most people do not use RIA even though they are in Silverlight world. Why is it so? Even on stackoverflow, the % of people asking as well as answering to RIA services question is very very low. Why is it so?
WCF RIA Services provides the following benefits:
Makes a WCF RIA service that supports IQueryable and IEnumerable; WCF RIA Services creates client-side proxy which allows you to send only expression trees over the wire from the client in order to get back just the data you need. For example: you can call a method in your ria service called GetProducts() but also add a LINQ lambda such as GetProducts().Where( d => d.Quantity > 50 ) and only the expression is sent over the wire to the server. The server does the filtering and returns just the matches as strongly typed objects.
Dynamic generation of OData, REST/JSON, and SOAP endpoints with little more than a single line per endpoint in your web.Config.
Ability to automatically flow business rules created at the middle tier into the client tier
Allows you to efficiently flow validations from the middle tier to the user
Allows property, parameter, method, object, collection, and changeset level business rules through simple data annotation validator decoration
There are some deficiencies:
Still does not support WS-* (will in 5) for RPC
OData provider is not queryable
Well, I have not yet heard of people referring to WCF RIA Services as black magic.
I believe there is a small number of people using it (compared to the number of people writing stuff in Silverlight), because it is younger. People may have been developing their Silverlight applications for some time now (version 3.0 came out in July 2009) using classic WCF Services.
WCR RIA Services is still new (version 1.0 came out in May 2010, the final SP1 in December 2010) and we all know the rule, "Never change a running system", so if someone already has a working WCF webservice, why change it? In my case, we experimented with Silverlight and WCF some time ago and decided to wait. When RIA Services came out we thought that was great and started working on a Silverlight version of our main application. It is much easier using RIA Services in a new project than chaning your webservice access in an existing one.
In addition to that it should be noted that Silverlight is not limited to business applications with database access using a webservice. Therefore there may be quite a few Silverlight developers who do not need any kind of webservice.
Another reason might be the fact that for web applications requiring a database other technologies like ASP.NET, ASP.NET MVC, even PHP or JSP (and possibly others I may not even have heard of) have existed for quite a while. And although business applications ought to look nice, too, it usually is not the top requirement to have all kinds of fancy graphics and animations, etc.
Finally, why are so few questions regarding RIA Services asked on SO? Well, they do have their own forum which seems to be quite active. (I use it as a resource when looking for answers but don't post there.)
Regarding the "black magic" part of your question, I believe it is the ongoing shift to convention over configuration. Compared to vanilla WCF, you end up writing very little code to build the client-server relationship. Also, the WCF RIA tooling does a substantial amount of code generation to achieve this.
More on convention over configuration on specifically with WCF RIA and generally at Wikipedia.
Is there a current and good example how to use WCF RIA Services together with Prism? There's a lot of information about each topic. But at the moment I can't see how to put everything together into a "real world" LOB application.
You can check the Telerik Sales Dashboard demo. It implements the "Composite Application Guidance for WPF and Silverlight ("Prism")" and also uses WCF Services. You can download the source of the application and run it on your side.
I am interested in finding a business model for a software product (iprocurement). However, I got quite confused between ASP (Application Service Provider) and Saas models. What are the differences?
Thanks in advance.
Though medium of delivery is the same i.e. internet, ASP takes a packaged-base approach while SaaS takes product approach. ASP provider need not be a manufacturer of the product. He can be a trader or a middleman who takes the responsibility of selling it and customising and implementing it when required. On the other hand, a system based on Saas model had been designed, built, delivered, configured and implemented normally by a single party who has total control of the system.
In case of ASP there can be multiple instances (or implementations) of a software running on a single server, suitable as per customer needs while in case of SaaS, a single software will serve to many clients allowing them to configure the service as per their requirement.
The fundamental difference is how software is built and used. ASP follows traditional development with a twist when it comes to deployment. It is built on data centric and it is deployed as an application with a centralized host sever. SaaS is built on service centric and deployed as web services.