I have a set of web methods that I am planning to convert to REST on top of MVC or WCF.
But I am little confused after reading few questions and answer on similar topic.
** My app is .NET 4, C# with Mongo database as backend which emits JSON **
Here is my use cases:
Persisting web form data (new user signs up, I need to save web form) &
show update status (success or failure)
User posts a new comment/reply. I need to save the comment in DB (async w/ jquery) &
show update status (success or failure)
User likes comment/reply. I need to save the like in DB (async w/ jquery) &
show update status (success or failure)
User updates title, tag or any other field. I need to update DB (async w/ jquery)
& show the update status to the user
User wants to view the next page of comments. I call web service and silently append
the comments.
In future I paln to open the API to other apps to talk to my app. So I need REST api to
handle that.
I am new to both MVC and WCF framework. So I need to learn either way I go.
But I would prefer easy and clean coding
Looking for light weight & faster solution (cheaper in the long run)
Please let me know if I have to specify anything else that might clarify my need.
Thanks
I would say it depends on your timeframe. If you need to put something into production within the next 3-6 months and your API is not going to be too large, and will stick to HTML/JSON then MVC will probably do you fine.
If this is a long term strategic project then I would keep an eye on http://wcf.codeplex.com. There is some excellent new stuff coming out of the WCF group for building sophisticated web apis.
Since you are writing a web application - I would go with MVC. You then get the testability benefits of MVC along with its inherent RESTfulness.
Tasks such as:
"Persisting web form data (new user signs up, I need to save web form) & show update status (success or failure)"
sure you can have a web app call a service to do this - but when you can get the web app and the call to do this all in a RESTful interface all inside of MVC - why go elsewhere? Rememeber - this stack overflow application is written in MVC : )
I would go with WCF, it is design for that purpose and if not all, most of the plumbing is done for you. With MVC to be used as restful service you will have re-implement few things to make it work like a real service.
Related
I am a total newbie to web ASP .NET Core MVC programming and see all these examples of bootstrap and forms with list boxes and simple controls.
In the old days, we used to have active x containers with custom controls that could acquire real time data updates, we used CORBA back then.
Is there any functional equivalent in WEB ASP programming? Does an individual HTTP request have to be sent every time an update is wanted? I'd like to have the server objects on the back end decide when it is time to send a change-driven data update.
Out of the box, you can't do this easily, however there's a library for it called SignalR.
You can use Server-Sent-Event.
We are starting a major upgrade of a large WebForms application. The logic will be split between AngularJS on the front end and .NET MVC on the back end. What are the criteria about where to put routing? I can put it in RouteConfig.cs on the server and have .NET to be responsible for routing; or I can use ng-route on the client, and use only WebApi calls to the server.
I see pros and cons both ways, and I was wondering if anybody has any decision criteria. Or some articles that I missed (Google has plenty on implementing the routes; but not on the decision to pick one over another).
I would argue for full separation of concerns, so routing on the client. Doing the routing on the client puts the client in control of what is being displayed. The server would only serve the raw data via rest.
This also allows you more flexibility in the future as well. Say in 2 year you want to ditch Angular for the next new client framework. All you need are client developers to implement the UI calling the existing endpoints, the server code would not need to be touched. Want to move away from .NET backend? No problem, just implement the endpoint in the new framework, not client could would need to be changed.
You should use both as your application is large.
let say your screens are divide on the bases of rule.
When Admin will login you will load all files related to that functionality and after that take benefit of ng-view and make that functionality as a single page app.
So in this way you don't need to load all files once. by ng-view you can also share data between different screens.
i've a question regarding handling of user logon while porting an application to MVC:
in the "old" WebForm days, developers simply used the SessionState object to set a user to logged-on, by -for example- simply putting the userobject into the SessionState (and this userobject holds simple properties like name/lastlogon/etc.)
this stuff worked very well for us, and i've seen lots of applications doing it that way
yes, i know there is this MembershipProvide-thingy, but i've never used it
Now, in MVC, everybody tells me that "using SessionStat for this is bad" and "apps built that way are flawed in design" and that "there are tons of security risks" and so on.
I've used this method because it worked for the app very reliable, it was simple to implement and it covered all stuff we need.
(Sure, there is the thing with recycling web worker process and emptying the session - but thats not a problem in our case, since the app runs for each country on a dedicated machine)
I've read tutorials, telling me to put that stuff in the DB and -attention- doing a request to the DB to check if the user is logged in, per EACH request? But: Under no circumstances, this is a doable way since i want to keep DB requests on a minimum.
So my question is:
A) whats wrong using this way also in the new MVC app?
B) whats the best way to handle this scenario in a newly built MVC app?
Regarding the session-in-DB-idea: instead of doing this, i'd rater setup an additional service, like a "session-manager" thats get query over the network, but such simple requests should not go to the DB - isn't that a good idea?
Any idea, hint /etc. is highly appreciated since this scenario is really confusing me :-X
A)
A fundamental principal of the asp.net mvc framework is that its stateless. Data is passed around using http requests and sent to the views in viewmodels. Web forms tried to maintain state with viewstate etc thats why you would have seen the logged in user in session approach. Thats not to say session shouldnt be used completely in asp.net mvc, there are some circumstances when it can be useful. Like maintaining a 3 step form process that has to be persisted on the last step. But generally we already have a recommended way to handle the user logins, and thats forms authentication
B)
For accessing the user object, you can create a custom identity implementing the IPrincipal interface and add the required user fields you need. Then set the custom identity in a global filter and access it in your action results. Regarding not wanting to query the database for every request, why dont you just call it for the initial request, then cache the result until the user is updated where you then can reload the object and set it in the custom identity again.
I'm writting an application that has many Ajax widgets (Kendo-UI to be percise). It's starting to get messy to have all those Ajax responses without the standard controllers so I was starting to consider making each entities their own controller. If I'm taking the time to do this, I figured I might as well go foward and do those as WebAPIs since I was planning to do this in a not so close future, but hey, it would be done already...
So my question is: Is it a good practice to use an MVC application's own Web API as a Ajax Widget feeds or is there any reason to stick with standard Controllers?
I've seen some arguments about performance, but I don't think this applies to this situation. I believe it was more of a "Controller calling WebAPI" situation which has obvious performance hits. But since it's already a client side Ajax call, weither it goes into a standard MVC Controller or a WebAPI controller shouldn't change a thing, would it?
Edit
Additional information regarding the project:
I am using Entity Framework for the data access.
I have a repository pattern going on with UnitOfWork.
I am using proper a MVC structure (EF POCOs AutoMapped to DTO POCOs in the repository and fed into View Models by the controllers)
This is a MVC 4 project on .NET 4.0
There is a lot of database relationships (specially for the object I'm working with at the moment)
I don't know about "good practice", but it's certainly not "bad practice". I see no difference whether you do it in the app or a different one.
I think its a good thing but only if what you are doing in the API is kept as generic as possible to other applications and services can reuse the API.
Both the applications I have written and continue to maintain use pretty much the exact same stack as your app.
I have recently re-factored one of the applications to use the API for all the common things like lists that I'm binding to Kendo ComboBoxes etc. in my views. Its a fairly large application that re-uses a lot of the same lists such as states, priorities, complexities across various Entities and views so it makes sense to put those in the API.
I haven't gone as far as going the whole hog through. I draw the line with things like this:
public ActionResult GetAjaxProjectsList([DataSourceRequest]DataSourceRequest request)
{
return Json((DataSourceResult)GetProjectsList().ToDataSourceResult(request), JsonRequestBehavior.AllowGet);
}
That is very specific to how the Kendo Grid wants the data back. Nothing else I have connecting to this app will use this data in this format so I keep it in the controller.
In short... I use the API for common things within the same MVC app and things that I allow to be used by other applications or services, like Excel.
I have an Asp.net MVC application which uses html5 and jquery on the client side. Management want to experiment with Silverlight as they feel it will give the end user the impression they are running a desktop application rather than web based application.
What I want is to create a silverlight version of the application but unlike a MVC application where html views are returned I really want to have data just returned and consumed by the silverlight application. So each time I go to a new page in the silverlight application only the data is returned to populate it (I do not want to return a xaml page which has the data embedded in it). So all my application logic will be in the silverlight application.
Since our application will be a multi-user system, one of the requirements is that when showing a grid of data in the silverlight application the grid must be periodically updated as other users add and remove records. Currently with the MVC app I have a timer which updates the grid with an Ajax call every few seconds.
I am not sure if I can reuse the mvc controllers and actions and just return data or whether I should go with RIA services as it may provide me with other richer functionality.
JD
RIA does provide with richer functionality, but IMO lacks the very reusability (interop with jquery for example) you'd need here. See Tim Heuer's blog on how to use Silverlight as a View with MVC here, and maybe add an extra parameter to your call's like (?mode=sl) and check for it in your controllers, so gather all your data you'll need for your views then
if (mode == "sl") return Json(data);
else return View(data);
Of course, life is not this simple, you'll have problems with Child Actions, ViewModels, etc. But it's a start.
On the other hand if you're just doing CRUD operations, and have written almost no business logic into your controllers, then fire away with RIA! IMO, the most important thing of them all is DRY!!! (Don't repeat yourself) So if you have lot's of code in Controller then don't rewrite it around RIA in SL again!
Both? :)
Create one or more repositories to contain your data IO and business logic and let your MVC actions and domain service methods surface what's needed.