The task is to create several JSPs, in which the user would be able to interact by inputting information, which would be saved on a database server, so the info can be called up later.
I'm not sure if this question is constructive enough or not, but I have no idea how to even start. I know what each one of the components means, but that's about it. I have no idea how the whole process works and I don't know what's it called, so I can't even search for it properly.
Could anyone briefly describe the process from start to finish how this system would work and what should be my first concern? I'm more interested in the JSP hosting (would Tomcat be a better choice, or is Geronimo much better in my case) and the connection of JSP to the database.
You need several components and layers for an application like that, so the first thing to do is select your technology stack so you don't reinvent the wheel and adopt best practices that your frameworks include. My choice, is Spring Framework.
Your JSP's represent the View Layer of your app. You can use JavaScript/AJAX to embelish your forms and sent data to your server.
The data that the user enters in the form is received and processed by the Controller Layer. Spring MVC has some neat collection of controllers for you to use. Once the data es ready, you can pass it to the Service Layer to execute Business Logic.
The Service Layer contains Business Logic rules. Spring Framework let this Layer to be simple POJO's, and to apply Transactional logic if you wish. It's highly probable that Service Layer requires to persist some data in the Database, so it invokes the DAO layer.
The classes in DAO layer have the responsability of storing data in the database. You can use several frameworks for this, and Spring supports many of them. Also, Spring includes some inherent JDBC support with templates included.
With that you can start your project. It should run with no problems in Tomcat, Geronimo or any Java EE Container
Related
Can someone explain to me why you can't connect to a MySQL DB directly through dart from a security point of view?
There is no hard guideline on whether to connect frontend directly to backend or not. It is just a design practice that has been widely accepted and evolved over many years.
Typical app structure consists of
FRONTEND -> SOME MIDDLE LAYER -> BACKEND
Where your middle layer handles all the interactions/processing with the database and the frontend uses this functionality with some sort of API structure. Having this layer is extremely helpful when the application goes to scale, it gives an added abstraction to the frontend.
It is not advisable to directly fuse your frontend(your flutter app), to the DB(MySQL) because any efficient hacker might use basic man-in-middle attack to know your DB structure/connections/queries(There are some pretty effective decompilers present out there), and alter your data and you might not even get to know what caused the data to update unless you've applied some checks on DB layer.
Also, your frontend logic needs to be more of end-user centric than to handle the data of the user. Any backend system(java, node, etc) gives you added functionality & freedom to parse and present the data from either side.
You can use the sqlite package available to store basic data, like your session tokens, your app configurations etc, but it is advisable to keep the main user data like the logins, etc in a separate place, or better yet, you can use the firebase plugin to store data in document structure in the cloud.
i'm trying to drop all database access on my swing application thats why i created an EJB module hosted in a jboss server where i put all my database calls.
My question is : what is the best middleware i can use to ensure effective communication between client and server without decreasing my swing application performance ?
I've seen that JMS represents a solution of my problem , but is it the best one ?
Please Help !!
JMS is preferably used for communicating between two systems where failure or downtime of one system leads to instability (i.e providing full availablity). Also db calls will be highly transactional so JMS is not the right approach.
You can either call the ejb from your swing action class, but it is likely to add a considerable amount of boilerplate code. Another alternative will be exposing web services that will in turn call the ejb's for db access. That might give you a whole service oriented design.
If it is possible, you can move your whole swing application to Dynamic Web application, that way it will give you 'n' number of options.
Reading through J2EE basics might help you to find the solution.
I am developing a game (ipad), the game will need an online database for storage, becuz it will need others players data to play multi-player stuffs.
I have been reading core data tutorials, but so far, what I read are all for internal iphone storage (using internal sqlite3 etc).
My question is that:
If I were using online webserver database (connecting/read/write/update by using php), do I need to use the internal core data?
More details for question 1: For example, I fetch a player's data like username, level, gold, hp, exp etc, do I need to wrap to core data, or I just simply create an NSObject for storing the player information, and using share manager to share with others classes that need it?
What are the tips and technique for developing iPad games with web-services(mysql via php HTTP POST). (FYI, I found this ASIHTTPRequest library, and I find it quite useful, and I am using it).
Core Data isn't primarily for storage. Instead it is a means of creating the model layer of an Model-View-Controller design app (which the Apple API uses.) Persisting the model to disk is really just an option.
Core Data handles both size and complexity in models. If your app just fetches dumb data from the web server e.g. a list of static values, then you probably don't need Core Data. However, if your app fetches data from the web server and then manipulates it in a complex manner, then Core Data will provide you many benefits.
A lot times, if you don't use Core Data, you can end up essentially rewriting Core Data just to manage all the relationships between your data objects and the rest of the API.
If you plan on working a lot with the Apple API, you should learn Core Data regardless of the source or destination of your data. It will save you a lot of time in the long run. The important thing to remember is that its not a database wrapper.
In my application, the entity database schema is created after application deployment based on inputs captured from end user, using a tool. I cannot use Entity Framework in this situation, since modeling is not possible without development environment (Visual Studio). The 'Code First' approach is also ruled out since it would require code generation which may lead to needless complexity.
Anyhow I need a Data Access Layer. I am therefore planning to introduce Data Access Application Block (DAAB) into my solution. Using SQL Management Objects (SMO) I can carry out the DDLs and for Data access I will use DAAB.
Now here is my confusion. Can I use LINQ for SQL technology on top of DAAB? I want DAAB to abstract all data access related complexities and then use LINQ to query. I also have a situation where I need to expose entity data through RESTful interface (read as OData). Would I be able to expose my data using WCF Data Services via DAAB?
LINQ is not supported in DAAB. DAAB is based on the good old DataSet and DataReader approach. This post has much more detailed answer with respect to role of DAAB.
LINQ support in Enterprise Library Data Access Application Block
I don't yet fully understand your scenario. If your database schema is created after deployment, then hows your front end application being developed against (as there wont' be any schema, if I get your question right).
If the schema is created after deployment what functionality is in your deployed application. Are you creating user interfaces on the fly using the dynamic schema that end user modelled?
Please do correct my understanding also good if you can give in some more info about your scenario.
Unable to determine what is the best way to connect to mysql database in struts..
We can always use DriverManger and Class.forName() to connect.
DataSource interface - but this has problems I am getting compliation error for
DataSource dataSource = (DataSource)context.getAttribute(Globals.DATA_SOURCE_KEY);
or when Action.Data_SOURCE_KEY is used. when searched I found that these variables are depricated.
How can I use connection pooling in struts?What is best place to place url,username,pass for database?DO i still have to use datasource configuration in same way in struts-config? Then why was this facility depricated?
Too many queastions but I cannot find a definite source to learn struts.
Struts doc can be but then revisions and backword compatibility are the issues which a learner cannot get easily... Pls suggest a good source to learn struts2.
Struts is an MVC framework, not a database access framework. You should use some sort tool for your Data Access Layer. Spring makes it really easy to manage connections, transactions, and the sort, and integrates well with ORM tools like Hibernate or the JPA implementation.
Where Struts fits in in this is that it will manage the request, delegate to an action, which in turn will invoke a service that uses your data access layer. You could put your DAL in your actions, but I wouldn't -- I would put them in a service.
Struts is a framework having the MVC approach. It makes you to create application in an efficient way. Connection between database is somewhat risk compare to someother connection.