I am creating an SPA (using visual studio 2013). The application gets data from the WCF service. The data generally involves C# collection. As the SPA is MVC based, I copy the data into Model objects and pass it to the view. Now, I am planning to use Knockout.js. Should I need to directly convert the data from WCF service into JSON or copy the data to Models (in MVC) and then convert them to JSON?
P.S:
My WCF service and the SPA lie on the same system. Currently I transfer the contents from the service to the web application using binary serialization and not in JSON format.
Probably the cleanest approach here is to simply return JSON from your controllers and not have MVC views (or WCF service) at all. This way you can keep the front end completely separate and the server code generally becomes a lot simpler.
Related
I have an ASP.NET Core 5 Web API that communicates with a SQL Server database using ADO.Net using stored procedures. This API is consumed in another ASP.NET Core MVC project within the same Visual Studio solution.
What is the best and most reliable way for the MVC project to handle pagination, sorting and filtering functionalities for the displayed results received from the Web API project?
Fully functional source code: https://github.com/krchome/WebAPICoreMVCClient
Regards,
Kaushik
When you design an API project separately, the idea is that you will keep all the logic and data fetching activities like sorting, filtering, and paging in the API itself. This makes the API self-contained, cleaner, and faster. UI will be responsible for sending the required parameters to the API which includes page no, sorting key, etc to the API and API will give the correct data. which you can consume from the UI and show it.
To which part of the MVC pattern belongs an API? Am I right with the assumption that it belongs to the view?
I'm talking about an application which provides an API to access data from the model.
Then these are conceptually different things. You are offering an API on your server (let's assume REST based); the API here is your server and the software which runs on it. That software may internally be built using an MVC pattern. An API request is handled by a controller, a model, and the response is output by the view. An API request uses all three parts of MVC. "The API" is what your software looks like "from outside".
If you consider the server you are connecting to through the API as a data storage, the API is a layer between the data storage and the controller/view.
In MVC architecture, the model contains a data storage with a service that controller or view can access to obtain the data.
In this case, API is the service, so I would say it is part of the model.
I have a Typical SOA web application which has the following components as expected.
The Web Client - Sprinv MVC
SOAP Services - Spring
The Reference Data is centralized which is exposed thru its own SOAP Services.
The SOAP webservice responses have codes for elements(like CountryCode, CityCode etc).
I need the suggestions as to what should be the best approach to for ex display the Country Description instead of the country code (which needs another SOAP call to reference data and same with other codes) on the web page ?
Few options are like:
Write a custom tag library which would do the necessary calls and get the data.
Fetch all the ReferenceData descriptions and put it into some kind of HashMap, add it to the model to be consumed by the web page.
Any other better ways please advice.
Since it's reference data, no one expect it to change very often, right? Retrieve them once and serve them up using #ModelAttribute. See here.
Spring MVC is still server side, so it can handle very large data e.g. all the street addresses in US. You simply need to make sure you add some sort of filter if you don't want to serve the entire collection. And simply partial update these reference data with the latest on regular basis.
I am new to the WebAPI. I have 4 entities:
Location
Service
Item
Application
I have read several WebAPI tutorials. They all seem to have CRUD methods in each API Controller that deals with single entity. One functionality that I need is to simulate cascade dropdown and cascade update where Location determines range of Service. Each Service determines list of Service Item. Each Item may be used in a list of Application. The question is
Do I create 4 API Controllers with CRUD methods?
I need all 4 objects on one form as List Boxes that allow multi-selection.
Along side the 4 List Boxes, how to show a list of combination of selected value that are saved to a database table?
Which javascript library or framework is the best for SPA (Single Page App)? I am currently leaning towards Backbone.js and HotTowel.js.
Thank you.
You could expose your service as an OData service. If you wish to support filtering, then you should use the separate OData NuGet package, and develop your controllers. In this case four controllers would suit.
Then, you can use a client side rich data library such as breeze.js to make building requests to the OData service straightforward. You would then use an MV* client side framework to provide two way bindings between the client side view models and the UI elements.
Hot Towel isn't a JavaScript library, it's a Visual Studio extension which allows you to create a new project as a starting point for your SPA. The template requires Visual Studio 2012 and the ASP.NET Web Tools 2012.2 update.
It uses breeze.js, Knockout.js for the binding, and Durandal.js for navigation, life cycle, and view composition.
I'm trying to learn web development.
I understand (mostly) the concept of MVC, but I'm confused about why an MVC model is used on the server side...like Spring MVC. Isn't the server side the Model and Services, and then the client side Services, View, and Controller (AngularJS even makes that pattern explicit on the client side)?
I'm really struggling with how the MVC model fits into or facilitates server-side development.
MVC is a pattern used by much more than just web applications. Any app with a UI could use an MVC pattern.
The idea is that you have a View (html, or a window in your OS, or even a report or something), and you have a model that represents the dynamic parts of that view. Then you have a controller that is dedicated to processing input and doing the "business logic" to generate the model and apply it to the view.
So.. for example on the Server you might have this MVC pattern:
A controller receives the HTTP request and processes it.
It builds a model
The model is applied to a view to generate HTML and send it back as a response.
On the client it will be similar (but a bit different in Angular's case):
A controller is used to determine and manipulate the model.
The model is then bound to your view via directives. (Angular is really more of an MVVM pattern, but it's similar enough)
The view is similarly bound to your model via directives. (this is where the MVVM part comes in).
The idea here is that both the model and the view are kept up to date by directives.
The controller just contains "business logic" for manipulating the model.
Clear as mud?
No worries. Just know this: It's just a common pattern. It's not "server specific" or "client specific". It can be used anywhere by anything requiring data to be scrubbed into templated output.
EDIT: More thoughts.
In the case of a Web API that serves up JSON (or even XML) on the server, you're still using MVC in most cases. This is because what you're doing is:
Process the request in a controller.
Build up the model in the controller.
Render the model to a "view", which in this case is a view that serializes it out as JSON.
In the good ol' days of yore, the client side was only a display. The server was responsible for communicating with the model, applying business logic, generating a view, and sending the static, rendered content back to the client (browser).
As the web matured, some of those responsibilities migrated from the server to the client. Now, the server-side is often a thin layer like RESTful API that stores the "official" business logic (rather than convenience logic on the client) and stores the model. But for performance and user experience, the client now stores a copy of the model in its own model layer, communicating with the server and/or local storage as necessary, and having its own controllers and view logic to provide an awesome user experience.
So does MVC still apply on the server? Yes! It's just different. The server often generates the initial view from which the client-side application runs (taking localization or internationalization into account, for instance) and still houses the official model. But more importantly, the "view" in MVC just changed. Instead of the server-side view being HTML, it's now JSON or XML that the client application consumes instead of just renders.
So for functionality's sake, we still use MVC on the server. But for an awesome user experience, we use MVC on the client-side now too.