I recently got into Silverlight development. So far I've managed to create a single Silverlight XAML view which pulls in data from an SQL Server Database using the ADO.Net Entity Framework and displays the data in a Silverlight DataGrid. I can also perform simple editing and update functionality on the data and persist it back to the database. At this point my understanding fails. From what I gather, the Silverlight Client Application is hosted inside an ASP.NET or ASP.Net MVC web application. Normally I would just build a website using ASP.Net MVC and use a few jQuery controls, etc., to spice up the interface on each view. How do I go about using these different Silverlight XAML views that I create in my ASP.Net MVC application like they were MVC Views? Have I totally missed something here?
RIA Models
There are two different models for integrating Silverlight (or any RIA technology) into your website:
Entire Silverlight application hosted in simple website
Silverlight controls integrated into a website with other interaction (forms, jQuery, etc.)
Either model works well, it's up to you to decide which works better in your scenario.
Silverlight communication with the server
Your Silverlight application is a plugin hosted in a browser, so it's best to think of it like jQuery or other client-side code. There are several ways to communicate back to the server:
RIA Services
ADO.NET Data Services
Custom WCF service
Other REST / SOAP communications you build yourself
Silverlight supports WebClient and HttpWebRequest, so you can get as low-level as you'd like in your client-server communication. I really recommend looking at RIA Services since it handles not only the communications, but also the validation rules.
Silverlight integration with HTML / Javascript
Silverlight can both call and be called from Javascript via the HTML bridge. This means that your Silverlight components can be as closely integrated with your web-page as you'd like. Silverlight can also directly interact with the DOM - setting and reading form values, changing CSS properties, etc. You can do just about anything you'd do in Javascript via the HTML bridge if you'd like.
In order to update your data model from your Silverlight application (which is running on your client's machine) is to utilize WCF (Windows Communication Foundation). Your Silverlight application will communicate to your server using WCF, and none of that has really anything to do with how you're serving up your Silverlight app (whether you're using Webforms or MVC).
Related
I am new to ASP.NET Core Razor(or MVC) page web development. I have an ASP.NET core web site deployed in a docker container and I have few other docker containers which are just .NET Core modules. Between the modules and the ASP.NET Core web page they would be talking over an RabbitMQ message bus or an Azure IOT Edge hub. Now if I get a message from one of the .NET Core module,I want to update the ASP.NET Core Index page view. I googled and I couldnt find a clear answer. Is polling using Jquery or Javascript and updating the view using Ajax the only option?
What you need is full duplex communication between your client (webpage) and server (asp.net core MVC).
With a classic MVC Razor webapp, communication is half-duplex; it is one way from your client to your server, and unfortunately, never the other way around.
Popular solutions that would enable what you want to achieve are:
https://github.com/websockets/ws
https://www.asp.net/signalr
I am quite perplexed over the use of Web Api in a MVC application being developed at my company.I recently joined the project and wondering why they are using this.The application uses JQuery AJAX functionality to pull data for each Tab in a MultiTab Page without refreshing it.
The application here is neither providing data service nor consuming any Web API service.This can be easily achieved without using REST verbs.It is directly connecting to database like a typical web application.
I am holding back myself to raise this question with the team since I haven't used Web API much but has a conceptual idea.
Am I missing something here ?
Microsoft's Web API MVC technology is typically used for external components to interact with the system - not generally a requirement for a standard MVC Web Application.
With that said, I'm not perfectly clear on the architecture. A few points of note:
jQuery AJAX is a perfectly valid (and usually preferred) method to retrieve information for tab pages - it provides a SPA (Single Page Application) "feel" to the site and generally improves performance all around. This does not mean that they're using a Web API
MVC is a framework used for many web applications, including Microsoft's Web API projects as well as ASP.NET MVC Web projects. The use of MVC doesn't mean that they're using a Web API.
A RESTful approach isn't just for Web APIs. Indeed, many find it a cleaner approach when using regular MVC Web Applications, as it tends to be more semantic to what actions are actually being performed (GET to get a view, POST to post data, DELETE, etc.) There's no real reason not to use REST verbs (which are actually just HTTP verbs, but called "REST" when we use them in a certain way). The use of HTTP verbs doesn't mean that we're using a Web API.
To conclude, The MVC Web API framework is it's own technology that's similar to MVC Web Applications, but more geared towards working with non-visual requests and responses, instead tailored to programmatic interfacing.
If this is indeed a Web API being used and not a case of MVC practices that you happen to be unfamiliar with, then yes, I think it's a good question to raise (at least from a technical standpoint - politically, maybe not, but we can't answer that for you).
A typical setup is to have multiple projects, one of which is a Web Application, which makes use of shared project(s) for domain/business classes and data persistence. Additionally, a Web API project is often used to provide access to the system for external components, but this is a separate "presentation layer" project from the aforementioned Web Application.
There may be cases where a Web API application is written as the core interface between the internal system and the rest of the outside world, where the MVC Web Application then interacts with the Web API, but this is a corner case that should only be done with specific reason, in my opinion (unless I misread, this seems to be the case you're stating?)
Using both MVC and WebAPI together in a ASP.NET Web application is quite common. Whilst you can provide HTML through WebAPI and you can provide JSON through MVC it's much cleaner to use the best technology for each.
WebAPI in particular lets you define an API once and then generates JSON, XML, ... for you based on the request.
do you know of any available architectural pattern where the most of the code could be shared between Silverlight and ASP .NET UI? I understand that Silverlight won’t work very well with MVC (although people are blogging on how they achieved this in fact what they did wasn’t pure MVC) and same applies to ASP .NET MVVM.
However, I’m pretty sure there is a pattern where all of your business and data layers could be re-used by both Silverlight and ASP .NET app?
The example of when this would be needed is if we created a web application using Silverlight for desktops and asp .net for mobile devices and iPad, assuming that everything but UI would be the same.
You could simply creat a business logic layer assembly that would be used by both the Silverlight and ASP.NET versions of the application, the UI would be different but they'd both be using the same business logic or whatever you want to call it. The trick however is that Silverlight is a client technology so the server-side piece would house all that shared logic and you'd need to then interface that through a web-service your client could talk to, but that goes without saying when it comes to Silverlight/client-side technologies.
Contrary to what you've heard: Silverlight works great with MVC!
As far as sharing code the simplest answer is to have a single implementation of your data layer and business objects in the MVC application and then expose this to your Silverlight application via web services.
Ideally this means that the only code in your Silverlight application is UI specific...
RIA Services works with both Silverlight and ASP.Net and provides both client and server validation via member attributes. Code is shared auto-magically between sever and client apps.
You can use WCF and/or Ria services for data layers.
A Guide to Designing and Building RESTful Web Services with WCF 3.5, this article explains the foundations of REST and how it relates to WCF. MVC uses REST as the architectural model. I am guessing one can use the .NET MVC to create web applications that have both a front end and an API point, but I am not sure if the safe way of building the API is to build it with WCF and then use it in the MVC as a controller.
Please comment if the question is not clear, I will add or modify the text.
Theres actually a third option, ADO.NET Data Servies. Anyway, here how I see them.
MVC REST: Gives you full control over how to expose your data, you have to write all the code to get it up an running tho, e.g. serialization, deserialization, all the CRUD methods etc etc. Worht metioning that this being an MVC site means you are limited to exposing your service via IIS over HTTP(S)
WCF REST: More automation than MVC, a much more solid frameowkr than MVC REST, i.e. caching, security, error handling etc (basically all the stff you'd have to write yourself using plain MVC). Being WCF, you can host this in a variety of ways (e.g WS-, TCP) etc.
ADO.NET DATA SERVICES: The quickest way to get up an running with everthing ready to use, all you need todo is configure the global.asax, however you have to use an Entity Data Model, which you many not want to.
Personally, I would use either ADO.NET DATA SERVICES or WCF REST to build an API, consue that API in MVC site and then expose that API either directly, or by passing it through another layer.
ASP.NET MVC can serve as a REST endpoint for light services work, so I guess the answer to your question depends on how you define "safe."
Clearly WCF is designed specifically for creating REST endpoints, with all of the security implications that are implied thereof, whereas ASP.NET MVC is designed to create REST endpoints which can be used by ASP.NET MVC itself.
The following article shows how to create a web service using an ASP.NET MVC controller:
Create REST API using ASP.NET MVC that speaks both Json and plain Xml
http://msmvps.com/blogs/omar/archive/2008/10/03/create-rest-api-using-asp-net-mvc-that-speaks-both-json-and-plain-xml.aspx
See also the following article from Phil Haack, which discusses an SDK the WCF team put together for users of ASP.NET MVC:
Rest For ASP.NET MVC SDK and Sample
http://haacked.com/archive/2009/08/17/rest-for-mvc.aspx
They are two different sets of technologies, only related by being built on .net
MVC is used to create websites and provides a model where URLs are routed to controllers and controllers deliver views to the user as the user interface.
WCF is a set of libraries in .net that are used to abstract the type of service (is it hosted in a windows service, as a webservice in IIS etc.) as well as the protocol (HTTP, TCP, MSMQ etc.) from the client and server which are communicating.
An MVC website may use WCF to connect to a web service, but that is just one of many options.
I have a prototype ASP.NET-MVC website which uses Ninject as a IoC container. All service-classes and repository-classes used by MVC Controllers are properly injected by Ninject. This is great.
The next thing I need to add there is Silverlight (version 3 to be more precise).
Silverlight will be connecting to my server using WCF service, hosted in ASP compatibility mode, to the same ASP.NET-MVC website.
What Silverlight needs is to 'download'/'get' a kind of ViewModel using WCF (the better name would be Client-Side Model). This is also possible - I imported WCF service and setup all security-related xml configuration files.
Here is the stuff I want to know....
Is that OK that model returned by WCF service is rather complex and includes arrays and inheritance (at array items' level)... or maybe there is another and better way to send it from server to client?
At Server-Side for regular asp-mvc stuff all service-classes used by controllers are injected by Ninject. How to inject services for WCF-service classes?
Do WCF service has an access to HttpContext.Current.Items? I need to grab from here logged User Id and a few profile-related data (regular forms auth. stuff).
EDIT
Ad 3. It's possible enabling AspNetCompatibilityRequirements
Has anybody ideas for point 2?
For the 1st Question.
Yes it is okay to return a complex structure, provided you have explicitly applied the '[DataMember]' attribute to each and every needed property of the Object/s.