I have created a silver-light website.
Silver-light has part for the client side and part for the server side.
Now, I want to crate another site in .net MVC 4.
I can't really understand two things.
The first is, where the site will be executed?? Client side or server side??
for example if i have a LINQ function in the controller, where it will be executed??
The second is, may i use WCF like in silver-light?? Or i can just add .edmx file(ado.entity file) in the project??
Yes you can able to use WCF service in silver-light application. You must need to add the reference of the WCF application
The answer to your first question is that MVC is a server-side technology. You can utilize JavaScript and other methods to utilize the technology for client-side functionality, but it requires the controllers, views and models to execute on the server.
The answer to the second question is that WCF can be used just like Silverlight in MVC, although depending on how you utilize it, depends on if it is consumed on the client-side or not. If you access WCF through the Controller, its done on the server side. If you consume it through AJAX/jQuery then you are handling it through the client-side.
Related
I need to calling our C# Methods from another server to perform some Action. I use C# in both servers. One is our Service Application, another one is a WPF application where I consume my Service.
Prefer I use a WCF or WebAPI service for Service Application?
Most People prefer to use Web Api, but web doesn't expose metadata for creating proxy by service.
which one is simple and better choose?
You may use either WCF or WebAPI, if multiple platforms (Mobile, Web, Other Service) are going to interact with your service, then I would recommend Web API, otherwise you may use WCF. Similar discussion has already happened in another question, please refer this link, hope this will be useful
Getting a web service and using android to consume them?
I am developing a application that is using backbone.js for most of the front end logic and was thinking of using sqlite for storage, but i have run into a few complications with it and need to switch to another NoSQL database.
I see on ravendb's site that it was created in C# and you need a .net compiler. Most of the docs are for ASP MVC type application. I can not go this root because we are developing this as a tablet application with no microsoft based technologies on the client side ( because we want it to work with android and apple )
The server however will be .NET and so i figured this might be do able. Just wondering if this is worth pursuing and if anyone has had any experience using ravendb? Or should i go for mongodb?
It is possible to expose RavenDB directly to a JavaScript application, sure. But it's usually not recommended. The main reason is security, but there are many other reasons to have a middle-layer.
For example, you often need a server-side location to perform application logic. Not everything can be done in the database itself, and if you do it all in the application then you will probably send a lot more data to the app than it really needs. Over the internet, that could mean a slow app.
The route many people take, is to use ASP.Net WebAPI, or ServiceStack, or another similar framework. This gives you a way to expose REST endpoints that your JavaScript app can call. You can connect to RavenDB from there.
Also, you seem to have the misconception that if you used ASP.Net MVC on the server that you couldn't target Apple or Android. That's just false. Whether you use a SPA approach or a traditional approach, you are delivering standards-based content, such as HTML, CSS, JSON and JavaScript.
Yes, You can use it. Actually RavenDB's server is a RESTful web service, which means you can work with it with any kinds of HTTP clients. These clients should be able to issue standard HTTP verbs like GET, PUT, DELETE etc.
ASP MVC is server side. I still at a loss as to why you would want to expose your db to a clientside piece. It is completely worth doing in a server side piece, but do not expose something like a db directly to your client.
I am learning to create RESTful services using WCF. There are a myriad of options to choose from. I am confused as to what should i use.
1.)REST Starter kit - Seems to be obsolete
2.)WCF WEbhttp service
3.)WCF Web API
4.)ASP.NET web api
I dont want to use ASP.NET MVC to build RESTFul services. I dont like the idea of services being in the same solution structure of a presentation layer. So what is it i should use?ASP.NET web api seems to be having going down the MVC route where the requests are handled by a controller which i feel does not fit into a "Service" terminology.
Take a look a that
Microsoft support for REST is moving to ASP.NET WebApi, but you are still free to use webhttpbinding to build your api if you want. The starter kit is no longer developed nor supported.
I don't get this part though
I dont like the idea of services being in the same solution structure
of a presentation layer.
You can build a webapi project in a different assembly than your web (presentation logic) project, and the solution it's only useful for you to keep all the things in one place, it does not affect the behavior of your projects/assembly, you can still use them/develop them independently. If you don't like the "style" of webapi (it's certainly "different" from what WCF developers are used to) it's another story.
I have a web site that needs data to be pushed to it. Unfortunately, I'm not aware of any other methods besides using HTML 5 WebSockets (I can't garauntee my clients will have HTML5 browers) and Comet (I'm not using java/tomcat).
I am not a big fan of using server-side ASP.NET for this particular project, and would prefer to use ASP.NET MVC or something like it. Is it possible to tie JavaScript in with a duplex service?
Well actually you can leverage the pollingduplex binding used for silverlight clients in javascript. There is an interesting blog post on this by tomek over here: http://tomasz.janczuk.org/2009/07/pubsub-sample-using-http-polling-duplex.html
I have a 3rd party web service, which I intend to use from 2 different applications:
a Windows Workflow (WF) project
a website
Right now, from these 2 apps I manually add the reference to the 3rd party web service & call the required method. This means I have this proxy layer generated in 2 places.
What am looking for is a way to create (am not sure about the correct word to use, sorry guys) the 3rd party web service in one place & have the 2 applications re-use it.
Can this be achieved using WCF, something like wrapping the 3rd party web service in WCF.
Is this approach right?any help or pointers would be a great help, haven't done much service based development.
Environment: The website, the WF project resides on 2 different servers (windows 2003 R2).
Environment(development): windows 7 enterprise/vs 2010 / c#
Thanks
More detail:
Think I dint use the right words in my first query, the following is what am looking for & why I need it that way,I need to call the 3rd party web service from a new WCF service.This new WCF service will be called from other applications(winforms/WF/website) instead of calling the 3rd party service.The idea is to able to switch the 3rd party service(vendore) without changing the implementation & in one place.We use an hr-xml format for request/response & all our vendors(exisiting or future) support the hr-xml format for the industry we are in.If we use a class library, then to change vendor, we should recompile & distribute the dll correct,we dont want to do that. I am not sure about an architecture to be followed to achieve this whole functionaity.Any pointers in the right direction would be a great help.
Thanks
Your quest makes great sense indeed - and I think it should be quite easy to accomplish:
create a new class library assembly ("WebServiceClient" or whatever you want to call it)
inside that new project, do you Add Service Reference - this will create the necessary WCF proxy classes and the config file
compile that class library
From both your apps, you should be able to reference that web service client assembly, and use it - you have the code for the client side proxy only inside that common assembly, but you can use it from any number of apps.
One point to remember: you will need to copy&paste the config for the web service to the main application's config (app.config for a Winforms/console app, web.config for a website/web app) since it cannot be read directly from a class library's config file (that won't be used by .NET).
In this case, I think, WCF service will be the gr8 idea. You dont want to recombile the client applications if the vendor is changed.