Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I´m going to build Restful Services Layer (Middleware) using Java/Spring/Eclipse. The goal of the service layer is exposing tons methods, that today exists in different systems.
The Middleware will have the standar layers for each Functional Unit, for example:
UserFacade
UserManager
UserBeans
UserDataAccess
I used to work with a single war project with all the clases inside. This is not good when working more than one team in differents requirements, with different deadlines.
As this is going to be a big project, I would like an architecture that simplify working with many teams in different requirements, and different deadlines.
First question:
What is best:
Create one JAR per Layer (Facade, Managers, Beans, DataAccess)
Create one JAR per Functional Unit (Users, Accounts, Bills, etc)
Both, one Jar per Layer / Functional Unit (FacadeUser, FacadeManager, etc)
Second question:
Should I create a Java Enterprise Application (EAR) with the Web application and modules?
or can I simply create a Web application adding the JARS?
I'd go with a micro services approach - breaking it down by functional units. Whether you use EARs or WARs depends on what application server you are deploying to. But since you specifically mentioned restful service endpoints, multiple web applications, each application exposing specific business functions would suffice. Breaking your project into multiple manageable applications is usually better than building one monolithic application.
This is a good read: https://stackoverflow.com/a/25625813/5150013
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I've to rebuild a swing based application to move it to a web environment. This application has some functionalities that already exist in another web application. I want them both to maintain the same functionalities, even those that are shared, but I don't want duplicated code.
In terms of architecture/technologies, what is the best approach to reuse as much code as I can? A third service-oriented application that controls all the business logic and have the web applications serve only as front-end? But how to avoid code duplication on the front-end?
Any feedback will be much appreciated.
very broad question so it's hard to give exact solution. think about separating common functionality as a different service. then both application can just redirect to it or use its api.
if that's not an option then try to separate that logic to a library that will be included in other application. good frontend frameworks allow you to do it also with frontend code (directives, plugins, validators etc)
You could work with dependencies transforming the common utilities, access data and business rules in libraries. In first moment you can make a refactor separating tiers and responsibilities and then you can incorporate Maven in you environment to generate and start to work with dependencies.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am a PHP web developer, organising my source code with MVC where all the web pages are in the Views, the business logics are in the Models, and Controllers handles users' requests, pass the right models to the right views. I am starting working with Java. What I know so far is BCE, which is similar to MVC. B (Boundary) contains GUIs, C (Controllers) and E (Entity contains all the models and models can represent database tables).
How to organise source code in Java, comparing to MVC in PHP? Is the following answer correct to this question?
In Java, source code be organised in layers:
- presentation layer
- service layer
- data access layer
Is organising source code about system architectures?
Organising code is about software architecture and doesn't depend on the language. That said MVC, layers, service orientation, micro services etc. are all viable architectures and the choice would depend on your needs/projects.
As with everything there's often no single correct way so start with what you feel most comfortable with. When you gain more experience you'll probably see room for improvement but I'd suggest to start simple and learn on the way.
As for package structure: you'd normally map one aspect of your architecture to packages which could be subsystems, features, layers, etc. Again the choice depends on your preference, project and needs. At work we are using feature/module + layer but that's just one way that works for us.
The MVC structure is also a viable organization of your classes in java.
You can also use the SOA architecture for multi-tier Services-oriented applications. In fact, the choice really depends on your need.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have a smaller project to organize my finance and several dates and TODOs. Know I need to create different Screens and must often connect to databases to get data. I saw that the spring framework supports some stuff for jdbc and dependency injection. The last point is very important, because I want that my Classes, which creates the screen should be loosely coupled and the code should be more clear.
Is it profitable to use Spring by small projects? I may use 3 components of the whole framework and because of that I'm not sure if it is "good" style to use a big framework like these for such a small project.
Thanks for every comment.
Whether you are going to use Spring Framework or not, that's completely your choice. But I am trying to explain you where your conception about Spring Framework is completely wrong.
You have said-
Is it profitable to use Spring by small projects? I may use 3 components of the whole framework and because of that i'm not sure if it is "good" sytle to use a big framework like these for such a small project.
From Spring reference doc
The Spring Framework is a lightweight solution and a potential one-stop-shop for building your enterprise-ready applications. However, Spring is modular, allowing you to use only those parts that you need, without having to bring in the rest. You can use the IoC container, with any web framework on top, but you can also use only the Hibernate integration code or the JDBC abstraction layer.
It is clear that, you can only use those modules of Spring, which are required for your project without having to bring in the rest.
Spring Modules
The Spring Framework consists of features organized into about 20 modules. These modules are grouped into Core Container, Data Access/Integration, Web, AOP (Aspect Oriented Programming), Instrumentation, Messaging, and Test, as shown in the following diagram.
Any way, although Spring Framework provides comprehensive infrastructure support for developing applications but for the novice user, it is tougher to use the framework quickly as it has complex abstraction and user has to spend more time in assessing the concept, function and it's uses in developing the application.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am working on a JavaEE web application which shall be able to fetch data from different sources. The data will be fetched and persisted in a database for later processing and reporting. I started with one default data provider covering a specific source but would like to design the application architecture in a way that either me or even others could write data providers / data provider plugins for different data sources.
The service providers could be implemented independed from the core application and could be packaged in separated jars. Once dropped to the web applications classpath the provider implementation would be recognized as service providers by the application core that is triggering the data fetching job.
I am looking for a standard way of implementing this SPI or extension points, but it shall not bloat my application's code.
I thought of "OSGI extension points" but this is more for rcp platform applications and mine is a web application. So I ruled it out for now.
My second idea is a combination of predefined provider interfaces and then the use of custom "provider" annotations to mark the implementing classes (the service providers).
What mechanisms / approaches / frameworks can you recommend to solve this architectural question?
Many Thanks in advance & Cheers,
Michael
I would use an event observer. During application startup, you raise a DiscoverDataProviders event, which has a registerDataProvider(...) method. The extension jars can observe the event and register themselves.
See http://docs.oracle.com/javaee/6/api/javax/enterprise/event/Observes.html
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Might be my question is abstract or out of context, but i am asking here since i have little idea how this happens.
I am wondering how big application/ platform break down there application in to multiple module and how they able to manage modules dependencies.
For example in some E-commerce application they tend to break down it in various modules like pricing,promotions,shipping.import/export and many more.
when we develop those application we hardly think about the underlying modules and how they have been designed to provides functionalists.
Most of those module are not web-applications but are standalone module and not deployed in the web-app as jar files.
can any one help me to understand how they break up things or is there any standard way to do this.any help/resources to get insight will really be helpful
E-commerce application [...] tend to break down [the application] in various modules
like pricing,promotions,shipping.import/export and many more.
[...]
Can any one help me to understand how they break up things or is there
any standard way to do this.
There are various ways from the technology point of view to modularize applications. Large systems are split into modules that must communicate with each others, and there are various technologies to do so: EJB, web service, libraries, database, file system, message queues, etc. It's way to vague to be answered.
In practice applications ten to be modularized according to the social structure of the company. This is Conway's law. Since pricing, promotions, shipping are usually different teams within the organizations, chances are that each team will have an engineering group, and the system will be modularized according to the organizational teams.
Try looking at the various maven archetypes available out there.
for example: http://appfuse.org/display/APF/Home
You can package many EJB jar archives within an EAR archive.