• Post Reply Bookmark Topic Watch Topic
  • New Topic

Servlet archtecture design for shopping database  RSS feed

 
David Jeang
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm working on a consulting training project to create a eCommerce online shopping application. Nothing big, just something functional and simple. That's why I want to structure it with the easiest maintainability possible. I've already ironed out the the database entities and how they'll relate to one another and even managed to establish connection to the database from my java application class. NOW I need to configure a user session on the web.xml, from what I've learned so far in my consulting, I can easily use jsp and servlets to have httpsession objects receive and send the information needed to and from the database, but the question is, how many do I need for a client's session?

Would maintainability be easier if I divide each entity's class actions to different servlets(a customer servlet, order servlet, product servlet, etc...), or can a single servlet handle an entire session without any complication?
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66261
151
IntelliJ IDE Java jQuery Mac Mac OS X
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Few experienced developers would argue that classes, including servlets, should be as small as possible and do one thing, and do that one thing well.

One large "God Servlet" is never a good design. *





* Not to be confused with a Front Controller servlet that fields all requests and then delegates to smaller units of execution. (See this article if interested in front controllers.)
 
David Jeang
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Okay, that gives me a much better picture of what I should do, but that brings a small nagging piece of info to my attention, namely the relationship between entities. For example, actions on the order entity would require a foreign key that belongs to the customer in order to associate it to that particular customer. I'm still learning about servlets, so maybe I have nothing to worry about, but if I structure the business logic so that each entity in the database is handled by a separate servlet, would it be possible pass the information from a customer servlet to an order servlet?

I think it's possible via the servlet parameters(name-value), but I don't want to end up getting in too deep before finding out I went an entirely different way to get a completely different result.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66261
151
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Jeang wrote:but if I structure the business logic so that each entity in the database is handled by a separate servlet

In my opinion, you are not approaching this correctly. The servlets structures should be designed based upon their needs as controllers, not the based upon the model.

would it be possible pass the information from a customer servlet to an order servlet?

Why would one servlet need to send data to another servlet? Servlets shouldn't be doing any work, they should be controlling application flow. If you have processing in one servlet that another servlet needs, it's a good sign that you are putting way too much code into your servlets.

Your model should contain all the logic needed to model the business. Think of it this way: if you remove the controller and view layer, and your model is not usable in another environment -- say, a desktop GUI -- then there's code that should be in the model that is not.
 
David Jeang
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmm...this gives me something to think about. Let's see if I can paint a bigger and better picture here.

My relational model has 5 entities that will persist information to the database: Customer, CreditCard, Order, Product, and LineItem. As taught to me by my consultant instructor, I've constructed a data object access interface and implementation for all five entities that will do at least the following basics:
1. Add a new row to the database entity
2. Remove an existing row from the database entity
3. Update an existing row in the database entity
4. Find a row in the database entity using the primary key
5. List all rows in the database entity

I then have an action class for each entity that will perform the all the verification logic needed for each of the entity's doa options before calling that doa implementation, which will set a connection to database and persist the data.

The goal in mind was to have the servlet set the request attributes to the HttpServletRequest object by calling the action class based on the value of the parameters of the request(It specifies what operation needs to be done), and the newly set attribute would be forwarded on the HttpServletRequest object to inform the client whether or not that the action succeeded in persisting into the database.

Are you saying the general flow I have in mind, 5 servlets to handle 5 action classes, is incorrect on some basis or level?
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66261
151
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think it's too limited and you are tying control to entities, where control is really tied more to what the UI will require.

Have you read through this article?

It outlines the duties of page controllers and task controllers. Page controllers, especially, do not align themselves naturally with entities and entity relationships, but with the design of the UI.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66261
151
IntelliJ IDE Java jQuery Mac Mac OS X
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also by thinking along the lines of "one controller per entity" means that you're going to be cramming all possible actions for that entity into one servlet. That means, the servlet does much more than the "one thing" that it should be doing.

As I said, in the type of application you are talking about (a pure Java web app, versus a modern SPA), each servlet (or other action unit) should do one thing -- not a bunch of things for one entity.

You might think "wow, that means there will be a lot of servlets!" and you would be right. That's why the Front Controller comes into play (see article).
 
David Jeang
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I double checked this with my consultant trainer, he agrees completely on your statement. In fact, he says this touches the subject on model-view-controllers and struts that he has not yet covered but plans to within the next day or so. Given that, I plan to study upon your article and listen in on his future lessons, then plan my architecture accordingly after digesting the new info. Should I have any further concerns or questions afterwards, I will post a new topic regarding my updated issue. Thank you very much.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!