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.
Related
I am to start designing & architecting a fairly big database business application (data entry, notifications, reporting, data export and usual security restrictions for data). Multiple clients - mobile apps & multiple websites will be there. Plan to use Asp.net MVC5 & Sql server for the development. Phonegap will be used to create mobile apps.
I plan to create an API. All interactions to the Database will be through the API (a REST API). This REST API will be created using Asp.Net MVC5. The front end will be developed as an HTML5 App which calls this API using AJAX. All interactions with the API will be through AJAX calls. Need to expose some of these services (5%) to third parties also.
For e.g. for a supplier management feature, there will be services like SupplierAdd, SupplierEdit, SupplierDelete, SupplierList etc. in the API. HTML5 App will call them through AJAX and do required. Necessary security will be imposed for these services using a login and token based security system.
Plan to use some Javascript frameworks like Angular JS for front end.
The entire application is one with around 200 DB tables and lot of relationships between DB tables. Business logic is only moderately complex. This is mainly a data storage & reporting application.
Is there any problem with this full API based approach ?
Another approach suggested is to avoid AJAX and Javascript and use ASP.Net MVC itself. No separate API will be there for each operation. .cshtml will submit to the controller method and this method will call the Business Layer and do operation. Services which are needed for mobile apps and third parties alone are exposed as API. Is this a better solution ?
The issue which I see for the second approach is that when more and more mobile applications or websites come in future, it does not offer needed flexibility. Also, exposure of some of the services to third parties will be difficult.
I request experienced architects to comment.
We want to write a new web site for customer using SQL DB
and implement only one specific client.
what the recommended technology to be used:
Peure MVC.net
Web API and client side using AJAX
I will be glad to hear the causes, the consideration and the cost.
Thanks!
I tend to favour a web api to handle all of the database work (via entity framework), but use MVC for my front end application.
This way you have all the flexibility of an API should you want to use different frameworks in the future (Angular, ASP.net 5 etc), but you can still have the pleasure of working MVC in your front end site.
I have built a few WebAPIs since it was born, including one supporting OData URL filters when that was new. I see now that OData over WebAPI has matured, I see it can serve service metadata.
Is it complete enough for Excel or other OData client tooling to plug and play as if it were a full WCF Data Service (ye olde Astoria)?
That's it. Thanks
OData V1-3 services can be consumed by the Data tab and Power Pivot data source import of Excel. While Excel's support for importing data from OData V4 services will rely on Power Query. That support is planned targeting early next year according to this: https://social.technet.microsoft.com/Forums/en-US/2169958f-9e2a-4fc2-a844-c0dce4c17a19/support-of-odata-v40?forum=powerquery
It is. In the past you had to do the right configuration or do a workaround to populate the OData feed from Web API correctly, to be able to consume it from Excel. Suprotim Agarwal wrote an excellent blog post about all the steps necessary to consume the feed from Excel, including creating and configuring the endpoint and what the steps in Excel are.
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.
I have read this document "http://jaydata.org/blog/how-to-use-jaydata-with-asp.net-web-api---i" and it shows a very clear and simple way to user web api odata, but in this example, all the data types are defined manually, and I read the words from the document
"The ASP.NET Web API provider does not use server generated metadata to setup the client. You need to provide the JayData library with some information about the data types your about to deal with. This at the moment you can only do manually. Version 1.2.7 of JayData brings Visual Studio development time support for autogenerating the client environment."
Currently, the version 1.2.7.1 is released, but I can't find any information that how to use some tools from jaydata to auto generate these data types.
Is there any document for this?
Yes, we promised it and we did a proof of concept but nobody has asked about it since that post, you're the first, so we think that our current users are happy with either creating the model manually or using WebAPI with oData where the model can be built either dynamically from $metadata or statically with JaySvcUtil.
I can not promise any date when we'll release it.
Can't you just use WebAPI with oData ?