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.
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.
I am making one application. It is a web form based application in asp.net c#. I want to include one feature in which the user can save details which he has filled and then submit it later. It really confusing for me to apply any function.
I have an assignment which manages some custom entities of dynamics365 sales application. Is it possible to create a separate web application which resides in dynamics365 sales portal?
The web portal will have 5 to 6 menus and various forms with edit update delete, paging, sorting, searching. All the operations will be done in custom entities of the dynamics365.
Too broad. Possible.
for web application - Need to do custom development using metadata messages in SDK. Can host it separately.
https://msdn.microsoft.com/en-us/library/gg509014.aspx
Inside crm portal - this is not a typical requirement inside portal solution, so am doubtful. But still Asp.net page template is not available like adx in 365 yet.
https://readyxrmblog.wordpress.com/2017/03/14/liquid-markup-in-dynamics-365-portals-part-1-hello-world/
Other possibilities:
If we want to go with custom code inside webform: similar discussion
My wild guess - May be you can go with navigation link for your web app from portal.
I would like to expose the SQL Server Views via OData Web API but I don't want to create separate controllers for each views as there are too many of them and they will only accept GET verb for all the views.
I thought I can achieve this using BreezeController but it looks like I cannot as it is obsolete now (The package which has BreezeController attribute is marked as obsolete).
Is there any way to achieve this with OData Web API that works with BreezeJS?
The [BreezeController] attribute is not obsolete. In fact, it is central to the "happy path" Web API controllers you see in the Breeze samples. I wonder what lead you to think otherwise? What package are you using?
I'm referring to the ASP.NET Web API!
The ASP.NET Web API OData is a different matter. Despite "Web API" in the name, that is almost a completely different approach to server development with its own behaviors and wire format. It does not use the [BreezeController] attribute and never has.
I'm not sure what you meant by "view" in your phrase, "separate controllers for each view". I think you mean what I would call "type". For example, in OData you'd expect a "Product" endpoint for your Product entity type.
AFAIK, the Web API OData approach demands a separate controller per type. That's what Microsoft's Mike Wasson says in his tutorial. He writes ...
A controller is a class that handles HTTP requests. You create a separate controller for each entity set in your OData service.
BreezeJS supports Web API OData too ... although there are limitations imposed by the current Microsoft implementation that may give you pause.
We are working through these with the OData team and hope to have better news in the coming months.
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.