I'm working on an ASP MVC project using C#.
My question is basically which is the best place to store some data that you get at a given part on your website, say for example, on the method that handles the SignOn of the user to the site, and then you want to access that data on another parts of the website, say on the classes of your model layer.
Suppose the data is just a list of strings, what would be better, store it as a list or wrap the list with a class?
Thanks.
It depends on how long you need your data to be around.
In the case of a single request you could use TempData on the controller
If you only want to store it per session (aka next time the user logs on to the site it will be gone) you could use the Session
If you want to keep it around forever then you will need to use some sort of offline storage, such as a database or file of some sort.
Good luck.
Um, pardon my ignorance, but can't you store it in the database?
What do you mean by "shared"? Shared by whom, by different pages but the same user? Or by different users?
If the latter -> DB.
If the former, either TempData, or if your talking about "authentication" data, then store it in the forms authentication ticket (assuming Forms Auth).
I think similar question was asked before here is the URL
Session variables in ASP.NET MVC
YOU likely store them in a session
which is the best place to store some data that you get at a given
part on your website, say for example, on the method that handles the
SignOn of the user to the site, and then you want to access that data
on another parts of the website, say on the classes of your model
layer.
A database is a great candidate for storing such information. Or a cookie if it is user specific and you don't need it to last very long. Or a file on the server. Or on the Cloud. Or write a P/Invoke wrapper around a C++ unmanaged Win32 function that will deposit the data on your company's intranet FTP server. The possibilities that you have are close to infinity. Just pick the one that you feel most comfortable with.
And I am explicitly not suggesting you to use Session contrary to what others might suggest you.
Related
I am in the process of developing a web based solution do replace an application we provide. The web application is a record storing application and each client would have different forms they would input data into and store. My question is: Is it possible to create a backbone Web Project, which would have minimal updates this would be like a container and be the same for all of our clients, and have the document forms which would be different among clients and need to be updated more often.
Any constructive comments for or against this with reason why would also be appreciated.
It sounds like what you’re describing is a multi-tenant system if you'd like to do some research on that term. Your web interface remains the same for all, but the records/documents are different for each client. It sounds like you might need login/access functionality that ties the records to a client ID (possibly stored in a database). According to how you intend to store the records (file system vs. database), you can control access either based on the client ID (foreign key to the doc tables) or you might want to create roles. This is a very high overview for what can become complex according to the specs.
I want to store some data during my site viewing.
Sometime i need to store large data like crystal reports and some times i need to store a string.
So which is best to use and when to use.
Where are these datas stored. i.e., Client or Server
Please go through this link:
Nine Options for Managing Persistent User State in Your ASP.NET Application
What you are asking is about State Management in ASP.NET. What you have actually listed is Server Side state management options.
You can made a choice of which to use depending on your requirement or functionality.
I will recommend you do some background reading on MSDN regarding State Management. I am not sure which answer you need here as your query is a bit generic.
Here is a link to get you started... http://msdn.microsoft.com/en-us/library/75x4ha6s.aspx
This is a very open ended question. Ass Julius said you need to learn more about the different ways you can store information. For example, Application is used when you want to store information on the initial startup of the site and make it available to all users. Session is for a single user so you may have many sessions open depending on how many users you have online at that time. Cache is also a way you can store information on the server. All of these are stored on the server so if you have hundreds of users online at the same time, server memory will be consumed holding all this information. Rule of thumb is to try to be conservative when storing information in these locations. Personally, I rarely use application and also try to limit my use of session to when it makes sense. If I were to write an app that used crystal reports as you are, I would probably use sql to store the paramaters of the report and generate the report from the parameters but it depends entirely on the needs of the user using the app.
You can find a wealth of infomation on this subject on line. Hopefully this will give you some information.
My question is how to best handle temporary data for an session. The scenario is similar to a shopping cart or like a bet slip. While the user is navigating the site and adding items with unique ID's. I'm only interested in the data collected this way if the user wants to commit it.
I'm developing in ASP .Net 3.5 with jQuery,JSON and a MS SQL DB.
As I see it there are a few possible ways to do this.
Perform a full post back to the server. Store every selections, update page controls accordingly.
Send selections via a Ajax request back to the server and update displaying control.
Build all functionality in JavaScript and store all values in a session cookie. Nothing being sent to server until user choose to commit.
I really want to consider performance here but I don't want to end up with 1000's of lines of JavaScript code..
Any suggestions of the best implementation with pro's and con's?
Cheers,
Stefan
Storing things in a session cookie is not a good idea, because that will be sent back to the server with every request. If you could find a way to store the state on the client without using a cookie, then you might have a viable client-centric option, but i can't think of anything portable off the top of my head. There are things in HTML5 and Flash that can do it, but you don't want to go there - yet, in the case of the former, and at all, in the case of the latter.
I'd use AJAX to post back to the server (with graceful degradation to a full post for browsers that can't handle that), then store the information in volatile memory there - ie not in the database. Write it to the database only when you need to. This is very easy to do in Java (you can associate information with the session), so i assume ASP.net has some way to do it too.
All three possibilities look good to me. The question, however, is: how much traffic do you expect?
Each of the options you presented suits better to a given scenario. Let's say you will have A LOT (thousand of thousands) users and not a lot of hardware available then you should probably try to minimize the number of requests to your app and store data in the client as much as possible before sending it to the server.
If it is smaller application then using Session or some other central database storage would be fine.
It all depends on your requirements.
I am having 2 applications Suppose A and B. I am having a webpage in Application A where i am Setting the Session and in Application B i want to retrieve that session.How can i do that with out using DB?
Sessions are application specific and I don't believe you can share data between two applications via the session. You will need to pass the data through some other medium. You could serialize it and pass it via a POST parameter. You may also be able to use a cookie. If it is really small data, you could just pass it in the GET parameters of the query string.
I agree with NYSystemsAnalyst - and here's a FAQ on how to transfer session from a classic ASP app to ASP.NET. The code can nearly be copied to do the same thing in this case.
http://www.tek-tips.com/faqs.cfm?fid=2943
When you say without using a Database I guess you mean without using a third party database. There is no way around the fact you need to store and retrieve data while protecting against simultaneous access of underlying data structures causing problems, and this pretty much makes it a database. You could implement something simple by allocating some shared memory and using semaphores to protect access to it. Also you could have app A inform app B of changes to session state and have app B track these. This communication could be done over a named pipe between the apps. What OS are you targeting?
How are you Identifying you user between the applications?
What do you need in the session?
Not sure, but a web-service or wcf that passes the session variables back and forth for a given username || id?
( maybe not the session exactly but a object you could used to build/populate the session on both applications... )
User start session in App A, just before they move to App B store a small version of the session variables needed in cache with high priority but short expiry( this is what the web service would look for).
User stars session in App B, App B calls web service to see if user was in App A... if so get variables needed for App B?
No DBs, but you will need to do some work...
And not even sure this will solve what you looking for?
Used something kind of like this to talk from Admin servers on Production servers...
But I wasn't passing the session itself...
Good Luck
Are there any alternatives\mods to .net Membership?
I find it quite restrictive;
Cant change Username, easily. You have to create a new user and copy the fields, but then you lose the primary key OR you have to edit the user table directly yourself.
Additional profile fields are stored together as one blob.
ASP.Net membership uses a provider model. That means you are completely free to implement your own membership provider, or even inherit from and extend an existing provider, as long as you follow the provider contract.
Plus one for asking about existing alternatives rather than trying to build something new yourself, though.
I'll go ahead and list my alternative here. I've rolled my own authentication library, and I think it's awesome enough to be publicly released... So I did. It's designed to stay out of your way and overall, it's pretty minimalistic. I don't provide a lot of out of the box user controls, but on most websites I've seen those built-in user controls are never used. So instead of trying to make yet more flexible user controls, I decided instead to make it brain-dead simple to create your own login controls and such.
The project is called Fast, Secure, and Concise Authentication, or FSCAuth for short. It is BSD licensed. You can download it over at Binpress or at Bitbucket
It's flexible "UserStore" model(the Form's equivalent of provider) enables you to form your database anyway you want. It can support plain text files, XML, MongoDB, Sql Server, and anywhere in-between.
Here's a list of things where I think it particularly excels over Forms Authentication:
Stateless Authentication System. There is no requirement to keep track of user sessions in either the database or memory. This makes it trivial to scale up to multiple servers requiring few(if any) changes to your authentication code
Use anything as a Unique ID for each user. That's right, no more GUIDs! Anything that will fit in a string is fair game
HTTP Basic Authentication baked in. You can enable Basic Authentication just on pages you want(or globally) and you can make the same calls as if they were using the typical cookie-based authentication
Hard to make insecure. Because of how it works and I leave as little core-code as possible to the end user for actually doing authentication, it's extremely secure and will stay that way unless you just really try to break it. I handle cookies, HTTP Basic Auth, and all hashing. You just give FSCAuth a database to put it in.
BCrypt support for hashes is trivial. How to do it.. In Forms Authentication it is almost not possible
I like it :)
Of course it's also lacking, and to be fair I'll include a few things that are lacking
Authenticating static files in IIS 6 isn't possible(yet)
There is no brute-force prevention(yet). This means that you'll need to make sure the same person isn't trying to hit your login page 200 times in 2 seconds.
It's not built into ASP.Net
No Windows or Passport authentication (with no plans to ever add)
As the ASP.NET membership model is built around Providers, there are a number of alternatives available.
By default, users have a ProviderUserKey, which is a GUID, and that's the Primary key of the database, so you should be able to write something to change their username if you want.
In terms of the profile, yes, the default blob is fairly annoying. You could take a look at the SQL Table Profile Provider which maps profiles on to tables, or fairly quickly roll your own.
As for the Profile there are a couple of alternatives out there. These two use either a table or let you call a stored procedure. Of course you can also implement your own. I personally got tired of using the Profile Providers, and found that dealing with the profile in my code was easier to control and contain.
As for the other issues, you can also implement your own provider. Microsoft released the source code to the SQL Providers so it can give you a starting point.
As far as changing the username goes, that can easily be accomplished by using the CreateNewUser() method and filling in the appropriate fields based on the current User, and then deleting the current user.
Profile fields are not part of the .NET Membership Provider model, but part of the Profile Provider. This is a highly debated topic and for most production machines, the correct way to go is to drop-in a better profile provider solution, such as this Table Profile Provider, which stores profile fields as you'd expect rather than as a memory-hogging blob. Alternatively, you can easily roll your own profile provider, check out the instructions here.
There are certainly .NET Membership alternatives, but most are buggy or have a small featureset. It really sucks to develop on top of one for two months and then realize it won't support all the functionality you need. .NET Membership is a proven solution and that's why it is used so often.