Currently I am using ASP.NET MVC 4 and jqGrid with server-side paging. The issue I am facing is that the data source come from a third-party web service and I need to implement server-side paging over the result retrieved from the above-mentioned service. Since I should follow the stateless nature of MVC, I am a bit reluctant to use Session or Cache. Your suggestions is much appreciated!
Check if your service provider is supporting OData. If yes, then you
need to look at it and it solves your question on completely
different way.
Cache and Session do not exist in the same context. Session is bound
to a single user, while Cache is shared for all users. It really
depends whether the data coming from the web service is unique to
each user or it is all the same for everyone. If it is the same,
then cache is optimal as using session in that case would just eat
your server memory with duplicate data.
If your data is not in extremely large amounts, you might even store
it on client-side by rendering table and then using table2grid
provided by jqGrid.
Related
I am migrating the my old ASP.NET Web Forms project to ASP.NET Core Web API and Frontend Angular. in my older application storing user information instace and it's values(like assigned groups,permissions,and other user information).i am going to use JWT i can't store all information in JWT,so should i continue session in my asp.net core application or retrieve this information from database in each request?
Is there any other Best practices are available in modern application development?
Multiple options for this, depending on what you need:
Angular cache. If the data is not sensitive, you can use the rxjs observables to cache some data on the application side. Nothing wrong with some data stored on the browser. Since you are coming from a full postback application, the SPA caching is most times equivalent to old Session object.
Depending on the implementation you might need some cache on the server side too. Since as mentioned you'll have multiple servers, I'd suggest only caching lookups and such, not user related data. If you implement stickyness with servers and sessions (not recommended), this is still an option.
Distributed cache. You might have heard of Redis and such? This is also an option to store cache data to a third service, accessible by all server instances.
It all comes down to complexity vs speed. If the queries are simple enough and lightning fast, then it might be useless to store them in any cache anyway.
I have a server on the WebApi2, and I need get all active users on the server.
How to implement it?
I think, maybe, save customerId after logIn in the session storage.
But I don't know how to implement it.
Or maybe exists some best solutions for it.
Help me please, with this issue.
You can access session object using this kind of code.
Keep in mind that Web API provides REST services, and is from a design perpective not meant to access Session objects, as its purpose is to provide stateless methods.
This of course does not mean it is not technically feasible, as you can see on this SO answer.
Use this article Adding Session support to ASP.NET Web API for example
as the entering point to find out the best solution.
I am working on Web API project for one of my web application using Asp.Net technology. The API will be an open API for different customers to use.
One of my customer who is going to use the API has a request wherein they want to poll the database and fetch all the information related to their customers and not just updated ones every 'x' interval. I feel its a very expensive call to make. Well we are still discussing on the best option possible.
Is their any alternative approach where in I can just sent updated records to my client and not all the records from all the data tables in the database?
Any help would be great as I am new in using ASP.NET technology.
Is there any way a c# server can store Sessions for web without developing the web in asp.net?
We have this web in angular and I want to improve performance of our server and I have 2 ways:
make some caching in the server with a singleton which store data
store sessions
Problem with 1 is that there are too many locks in code which im affried will cause a bottleneck (such as User log in, insert him to a "logged users" list for future locks on the user object).
So 2 will probably works best, but, is there anyway to build such thing? I can seem to find any reference to such thing without using the asp.net web.
Comminucation in web is done via AJAX request so I think, perhaps im wrong, that I can't maintain a TCP connection with the web so Reactor type server cannot help me.
TIA.
Maybe StateServer will solve your issue. You can store sessions via StateServer service in another server. Then you can manage it easily.
I am currently developing a WPF client application which uses Linq-to-SQL for the typed table objects and to wrap around an abundance of CRUD stored procedures in a MS SQL database on an external server. I do not foresee manipulating data directly via the context, only the stored procedures.
My two biggest concerns are:
1) Database security
2) Flexible architecture
As far as I can tell, since the application will be readily available for download via the internet, storing database connection information in the application itself is not an option (for security reasons). I feel my only option is putting my DAL in a web service.
User credentials can be passed along on a per-operation basis and database connection information will be stored safely on a secure web server.
I am curious as to whether this is method is valid, and if so is it optimal? Can I easily serialize Linq-to-SQL objects (table and stored procedure results) to send back and forth between the client and the web service?
Thank you in advance.
You are right, if your application is used over the internet, you pretty much have to put a middle tiers in there.
If what you are doing is primarily CRUD, I think a good idea would be to take a look at ADO .Net Data Services. It's an efficient way to expose data through a REST interface, and you get a client library to access your data in a typed manner on the client side.
It supports the usual ASP.Net security mechanisms (such as Forms authentication, membership provider and so on) so that you can secure your access points based on the user's credentials (and for that you can use the Client Services that can take care of authenticating between your app and your server).
Hope those pointers help.