I'm still new to MVC programming in Java. My question is, in what part of the program is it best practice so store user information? I have a login form and I handle the login in one of my models. What's the best way to make the user data available to the entire application? I was thinking about adding field variables to my model and simply storing the data there, but since I have several models I wouldn't be able to retrieve the data from other models. Is it a good idea to create an object that stores the user data and calling that object from all models? Or is there a better approach? Thanks!
First of your question is too generic an is risking its closure.
Your gut feeling to not mix data is right. Keep whatever user data together. Maybe for now it's just a username but this kind of data tend to grow over time and you want this flexibility later.
Think about where you need that data most. User data is needed for authentication, authorization and tracking.
If you think of the relation of user data and user generated data, or the interaction between content and user data, how would you structure such relations?
If you think about performance, which subset of the user data is at least necessary to fullfil your requirements?
I know I am wage but your question is wage itself.
Try to step back from your code and think more about the architecture of your software.
Related
I am planning on creating an android application sometime in the future in which I'll want it to display a lot of constant data on the screen.
I'm not sure the best way to do this but I see two options:
Storing the data within the code itself such as creating a constants class.
Using an embedded database to hold the data.
I'm guessing option #2 is the best way? But it just seems weird using a database if I'm not going to be doing any updating to the database, I would only be selecting.
The total amount of data that I need the application to display is maybe about 400 lines consisting of a string and two integers...
Is there a different way people use for such a situation that I don't know about?
But it just seems weird using a database if I'm not going to be doing
any updating to the database
I am totally disagree with you. Database is not only for updating. It can be used as a better storage and definitely a best way for searching. So as you want to preserve the data then it is definitely wise to use database.
But if you want to handle data which will not persists , i,e you will use different datas for different run then you can use temporary class or other data structure to store data.
Finally, If you are planning to have portability then File storage is an easier solution.
SO you can see, that it totally depends on what you want.
I want to get the name and picture of a Cub Scout, the Cub Scout details, the awards and details for each award and display these details in a view. Is it best to get each set of details from the server side, pass it back to the client side and display it or get all the information at once?
I would opt for option 2. However, I thought I had better check.
Regards,
Glyn
Unless your query is returning some huge dataset, then multiple queries probably aren't necessary. If load times are too slow when you implement your queries, consider paging your results.
When showing a view with all records from db, it is usually a good practice to show minimum data for each row with a link to more details for each row for better user experience and less load time from query.
Now when user click on more details, other detail data of that particular row should be fetched.
I agree that if the size of the information is not that big, probably is a good idea to get it all at once. All depends on your UX and you backend design.
Are you expecting to show the info according to user interactions?,
Are you going to reuse part of that information somewhere else in your app?.
Are you caching query results?
Is you do.. then you might consider to have a few methods to get the information. Regarding your page controller, unless you are not using ajax, you may create a facade (this pattern ) to integrate all those partial methods.
Let me know if you have any questions..
Thansk!,
#leo.
Get the benefits of Asynchronous call load as less data as possible on on-load and make Asynchronous calls when data needed.
Two main reasons to go for Asynchronous :
Reduce the traffic travels between the client and the server.
Response time is faster so increases performance and speed.
I have web application based on jsp and spring mvc where i need resolve this task :
The user must be able to add new instances of the main entity using wizard dialog. The wizard consists of 3 steps:
On the first step there must be a form which allows filling main entity’s fields, including association with the entity related as many-to one (it’s recommended to use drop-down field). The form should contain fields of different types: text, number, date, radio button, etc. Some fields should be required and some are not.
Example: input name, surname, birth date, phone, number of kids, select gender (radiobutton), department (drop-down), etc.
On the second step user fills additional attributes, including association with the entity related as many-to-many with the current one.
Example: associate employee with skills that (s)he has (checkboxes), add some note (textarea).
On the third step all the fields from previous 2 steps should be displayed as read-only fields. The user should confirm saving this data into database. After the user confirms saving, the data should be saved into database, and user should be redirected to the page with the list of objects.
How can i transfer and hold information without using sessions(Http session, session scope)?
You need to keep state across multiple server interactions. There are several possibilities, in general factors such as the size of the state data to be retained influence our decisions.
It sounds like you have some small number of hundreds of bytes here, so you're not particularly constrained by size - a few Megabytes would be more of a challenge.
First possibility, keep it all in the browser in JavaScript variables, no actual need to send anything to server. This is typical of a modern dynamic Web UI, where the server serves up data rather than pages. Sounds like you're in a multi-page world so discount this option.
Second, just put some data (possibly encrypted, in a cookie) effectively the browser is keeping the data for you, but it's shared across the pages.
Third use Http Session state - you case does sound very much like a typical candidate for a session. Why do you want to avoid it? Depending upon your server's capabilities this approach may not give great resilience behaviour (if the state is on one server instance then all requests for a session must be served by the same server). Note that HTTP Session and EJB Session Beans are not the same thing, HttpSessions are lighter weight.
Use a custom session "database" - maybe literally a SQL database maybe something lighter. For larger scale data entry cases, where a user may take 10s of minutes to complete many pages this may be the best option - the user's work is saved should they need to break off and resume later. It's more development work and you need to look at housekeeping too, but it's sometimes the best option.
In summary: be very clear why you reject the "obvious" HTTP session technique, in terms of simplicity it's where I'd start.
I am busy practicing on designing a simple todo list webapp whereby a user can authenticate into the app and save todo list items. The user is also only able to to view/edit the todo list items that they added.
This seems to be a general feature (authenticated user only views their own data) in most web applications (or applications in general).
To me what is important is having knowledge of the different options for accomplishing this. What I would like to achieve is a solution that can handle lots of users' data effectively. At the moment I am doing this using a Relational Database, but noSQL answers would be useful to me as well.
The following ideas came to mind:
Add a user_id column each time this "feature" is needed.
Add an association table (in the example above a user_todo_list_item table) that associates the data.
Design in such a way that you have a table per user per "feature" ... so you would have a todolist_userABC table. It's an option but I do not like it much since a thousand user's means a thousand tables?!
Add row level security to the specific "feature". I am not familiar on how this works but it seems to be a valid option. I am also not sure whether this is database vendor specific.
Of my choices I went with the user_id column on the todolist_item table. Although it can do the job, I feel that a user_id column might be problematic when reading data if the data within the table gets large enough. One could add an index I guess but I am not sure of the index's effectiveness.
What I don't like about it is that I need to have a user_id for every table where I desire this type of feature which doesn't seem correct to me? It also seems that when I implement the database layer I would have to add this to my queries for every feature (unless I use some AOP)?
I had a look around (How does Trello store data in MongoDB? (Collection per board?)), but it does not speak about the techniques regarding user_id columns or things like that. I also tried reading about this in some security frameworks (Spring Security to be specific) but it seems that it only goes into privileges/permissions on a table level and not a row level?
So the question is whether my choice was appropriate and if there are better techniques to do this?
Your choice is the natural thing to do.
The table-per-user is a non-starter (anything that modifies the database structure in response to user action is usually suspect).
Row-level security isn't really an option for webapps - it requires each user session to have a separate, persistent connection to the database, which is rarely practical. And yes, it is vendor-specific.
How you index your tables depends entirely on your usage patterns and types of queries you want to run. Is 'show all TODOs for a user' a query you want to support (seems like it would be)? Then and index on the user id is obviously needed.
Why does having a user_id column seem wrong to you? If you want to restrict access by user, you need to be able to identify which user the record belongs to. Doesn't actually mean that every table needs it - for example, if one record composes another (say, your TODOs have 'steps', each step belongs to a single TODO), only the root of the object graph needs the user id.
Is it a bad practice to expose DB internal IDs in URLs?
For example, suppose I have a users table with some IDs (primary key) for each row. Would exposing the URL myapp.com/accountInfo.html?userId=5, where 5 is an actual primary key, be considered a "bad thing" and why?
Also assume that we properly defend against SQL injections.
I am mostly interested in answers related to the Java web technology stack (hence the java tag), but general answers will also be very helpful.
Thanks.
That bases on the way you parse the URL. If you allow blind SQL injections that is bad. You have to only to validate the id from the user input.
Stackexchange also puts the id of the row into the URL as you can see in your address bar. The trick is to parse the part and get did of all possible SQL. The simples way is to check that the id is a number.
It isn't a bad thing to pass through in the URL, as it doesn't mean much to the end user - its only bad if you rely on that value in the running of your application. For example, you don't want the user to notice that userId=5 and change it to userID=10 to display the account of another person.
It would be much safer to store this information in a session on the server. For example, when the user logs in, their userID value is stored in the session on the server, and you use this value whenever you query the database. If you do it this way, there usually wouldn't be any need to pass through the userID in the URL, however it wouldn't hurt because it isn't used by your DB-querying code.
To use the database ID in URLs is good, because this ID should never change in an objects (db rows) life. Thus the URL is durable - the most important aspect of an URL. See also Cool URIs don't change.
Yes it is a bad thing. You are exposing implementation detail. How bad? That depends. It forces you to do unneeded checks of the user input. If other applications start depending on it, you are no longer free to change the database scheme.
PKs are meant for the system.
To the user, it may represent a different meaning:
For e.g.
Let's consider following links. Using primary-key,it displays an item under products productA, productB,productC;
(A)http://blahblahsite.com/browse/productA/111 (pkey)
(B)http://blahblahsite.com/browse/productB/112 (pkey)
(C)http://blahblahsite.com/browse/productC/113 (pkey)
User on link B may feel there are 112 items under ProductB, which is misleading.
Also it will cause problem while merging tables since PK will be auto-incremented.