Online store strategy question

Discussions

Web tier: servlets, JSP, Web frameworks: Online store strategy question

  1. Online store strategy question (2 messages)

    I am writing a JSP-based online store development kit, to be used by merchants and small organizations to develop and deploy a web storefront. I have a technique question I wanted to bounce off the people in this forum.

    Currently, my prototype uses a loose MVC-style design. Model objects, such as Customer, Order, and CreditCard, are ordinary JavaBeans (not EJB's, just regular local JavaBean classes). They have methods to persist themselves to a database, getters and setters, etc.

    While I could use Servlets for controller logic, I am using JSP's at present. View functionality (displaying the page), is, of course, using JSP's.

    A colleague is developing a similar product using ASP's and VBScript. Naturally, we compare notes a lot.

    While his product is tied to Windows and IIS, and to MS Access or MS SQL Server, mine is more flexible in terms of OS (any that can run Tomcat or other JSP/Servlet container) and database (any datasource with a JDBC driver).

    However, he pointed out an "ease-of-use" strength in his product: a customer can edit the ASP's to his or her heart's content, and not recompile anything. This makes any database schema additions very easy to do. For example, the customer might want to add a column to the Products table, one that I did not think of.

    With my product, they'll need to play with the SQL in a JavaBean and recompile it. Then they'll need to redeploy the JAR/WAR file. Not so if I'd crammed all the logic into a JSP file, instead.

    I get the following benefits doing it my way:
    - Lots of code re-use. Many controllers can call order.submit(), for example. Thus, it's easier to maintain and expand.
    - Mildly better security. Exploiting a bug in a web server or having incorrect web server permissions would be less obviously harmful. There isn't any SQL in those JSP files to learn from or modify.

    Having the model objects out of the JSP's is the way I learned to do this sort of thing. However, my friend has a point in the "how easy is it to modify" area.

    I think I will leave my stuff the way it is. However, it has occurred to me that I could indeed do it all his way. I could do away with the model objects and supporting class files. I could take a less OO, more procedural, approach, and have task-oriented JSP files to do things like working with the database.

    What do you think? Doing it that way would make it like some Perl-based store product (such as Mountain-net's WebCart). But are the security concerns and cleaner OO design benefits worth sticking with JavaBean objects and the useBean tag? I tend to think so, but would welcome comments and opinions.
  2. Well, your thought of using the OO concepts in the Java way is better off as compared to your friend's .NET way b/c of so many .......

    I still think that you can also give a GUI which can add any number of columns to the user( a maintenance screen), so that the same column can be retrived while displaying also.

    Use resultSetmetadata to take the column labels and the resultsets to take the values from.

    Hope that problem of urs can also be solved. I think your customer need not even touch the JSP or compile it or edit it that way.

    Good luck

    PRASATH B
    bp8475@sbc.com
  3. Thanks for the comments!