what would the good approach?

[Punit Jain]

Hi,

i am planning to develop a project (web-application). from logical point of view it will have some mathematical calculation and i will need to deal with lots of data and users.
i was thinking of using some framework (i e. spring).
but later my requirement could extend and i may need to develop mobile apps and desktop apps for the same project, and i wanted to reuse the code as much as possible?

using a framework would be a good approach? why? which?

or should i keep all my logic in simple pojo's? and go ahead with core java?

[K. Tsang]

So your foresee your app will be web-based, desktop/GUI and mobile. That's nice vision.

For me, allowing maximum reuse of say business logic and utility classes would be key. Doing these business logic in EJB will at least allow you to use in both web and GUI (not sure about mobile).

Talking about mobile, you may consider mobile web meaning it's a web app but the screens and stuff fit on a mobile device. This then surely can reuse EJB business logic.

Depending on how complex your design will be, separating the parts into its own jar libraries may be a good idea. That way you wouldn't need to duplicate code in all apps. The EJB too is just a jar like any library when put in web and GUI.

[Ulf Dittmer]

You can preserve the flexibility to reuse your code by structuring it in appropriate layers. The business layer containing the logic should be independent of the view layer (which may have several modules for mobile, web and desktop), just like the data layer should be independent of the business layer so you can change details about data storage without it affecting data use. You could additionally make it so the business layer is accessible via a REST API, and then some (or all) of the frontends would then use that API instead of making direct method calls. That is a strong trend in the industry currently.

This is part of the overall design, before you even start thinking about implementation questions like whether to use a framework, and if so, which one.

[Punit Jain]

Thanks you for your replies.

so i have created a rough architecture, does it looks good? what improvements can be done?


also if we look in terms of MVC, here my presentation layer is working as controller as servlets i would be using to passing the request from client tier to business tier?

[Ulf Dittmer]

The distinction between client tier and view tier is spurious. For example, Swing *is* the client. Same for Android/iOS. For the web, JSPs create the HTML which *is* the client. So I don't think that distinction is helpful.

Whether or not you use EJB is independent of the high-level design you're capturing here. You can, but you don't need to. And the whole point of tiers that is that their implementation should not influence other tiers - so the use or non-use of EJB has no bearing on the kinds of clients that can use it. Just mentioning that because of your remark regarding Android/iOS.

As I said before, you should think about how a remote client (Swing, mobile) will access the business tier, and plan for a REST API from the start.

[Punit Jain]

Thanks and my apologies for responding late on this.

i just have a one confusion what if i use Plain POJO here instead of EJB's?

yes there are some advantages of using EJB's i will not need to care about transaction management, Threads and all.

but these all i can manage independently also, since i am making this for learning purposes, should not i go with plain POJO?

[Ulf Dittmer]

Using EJB is certainly optional. Not knowing anything about your problem, I would recommend JPA as the ORM tool.

[Punit Jain]

Ulf Dittmer wrote:Using EJB is certainly optional. Not knowing anything about your problem, I would recommend JPA as the ORM tool.

okay, here is my problem.

A web application (for now but later i am planning to extend to desktop and mobile apps) which will has following features :

1.> sign up and sign in.
2.> users can login to their accounts and manage their expenses.
3.> like if there are four peoples (room mates) are living together they can easily manage their expenses, records, whom paid, with whom that amount needs to be distributed bla bla.

[Punit Jain]

kind of this website : http://www.shortreckonings.com/

[Ulf Dittmer]

Tool/framework decisions have nothing to do with the requirements, but rather how well they serve your architecture. There are also pragmatic issues like the pre-existing (or not) knowledge of the team that writes and/or maintains the code.

[Punit Jain]

Ulf Dittmer wrote:Tool/framework decisions have nothing to do with the requirements, but rather how well they serve your architecture. There are also pragmatic issues like the pre-existing (or not) knowledge of the team that writes and/or maintains the code.

hmm.
and i am the only one who would be doing everything