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.
Related
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
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 9 years ago.
Improve this question
I am very confused on what to use in developing a web application. If you can develop a web service using Java se restlet, then why should you bother using Java EE. What are the advantages of the one over the other? When and why should I use each?
Using something like Restlet doesn't necessary exclude JavaEE (you can use RestLet within JavaEE platforms).
Traditionally, JavaEE containers provide standardized services to applications. If you wanted to have a way to store your data transactionally, you'd write some EJBs because you didn't have to come up with the transactional model. The container provided that. You just focused on the entity and session beans that are specific to your domain.
Spring came along and provided a lot of the same capabilities in its own implementations (sharing some specifications and coming up with their own). But at the end of the day, you're using a common model for doing stuff.
JavaEE (or Spring) aren't limited to transactional models. JavaEE incorporates Servlets which in turns supports a raft of Web application frameworks. But, then again, many applications like tomcat support servlets without supporting the full JavaEE umbrella of specifications. JavaEE containers can supply JMS servers if your application requires asynchronous messaging, as well as standard means to define JDBC DataSources.
You'd typically use a JavaEE container like Glassfish/JBoss, if you want to have a lot of enterprise-level features without having to set them all up yourself.
You can do all the same things in Spring/etc, which is just a JVM, but you're also setting up all those services yourself (kicking off your own JMS servers, for example).
Historically, JavaEE containers were seen as large, resource-intensive applications which drove a lot of the Springs of the world to piece together just what you want/need. More modern releases of JavaEE containers are starting to buck that trend, though.
You really need to know what your application wants to do and look at what tools out there will provide you with what you want. Barring that, just grab Glassfish or something similar and have a play.
Hope this helps.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
Hi I'm looking for a simplified overview of EJB3 components.
I seem to understand most of the pieces of the puzzle, but can't quite get them to fit together in my brain as a full picture. I've developed numerous web applications (wars) that have been deployed on Tomcat before, but not a full-fledged EE application (ear).
I would like the overview to be as generic as possible. I'm not looking for a tutorial on how to set up EJB3 on Glassfish built in NetBeans or some other vendor specific tutorial that's more about the IDE than the technology.
I keep reading about Java, ejb-jar, web and ear modules but am not clear on what these different modules contain and how to use them to put together my app.
In my case, I want to write a simple database CRUD web application.
The first step is simple; create entity classes that model the database tables my app will be using. I plan on using annotations. Should I create a jar that contains just these enity classes? Is this the ejb-jar module (sometimes referred to as the Java module)?
Next, I'll need some business logic classes that make use of the entity classes. These are the session beans (stateless or stateful) correct? Should these be packaged in the same jar as the entity classes or a separate jar?
Finally, I'll need some sort of web interface (I'll be creating a JSF portlet) application that makes use of the both the session and entity beans. Together with the above jar(s), this will be my war?
Assuming the above to be correct, what is involved in creating an ear?
Forgive me if this post is vague, but I'm having a hard time defining what it is I don't understand.
Thanks for any help!
Packaging EJB 3 Applications by Debu Panda (author of EJB3 In Action) is a very good resource and will give you a good overview of the components that compose an enteprise application and how to package them.
PS: I don't want to make things more confusing but note that you can now package your EJBs directly in a WAR in Java EE 6. If you don't have strong modularization requirements, this simplifies things.
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 8 years ago.
Improve this question
I've used Spring and Spring.NET quite a bit, but I would like to see what else is out there. Can anyone recommend a good Java or .NET framework that I could try to learn?
Here is a list of IoC containers from the good Mr. Hanselman...
Castle Windsor is very popular, you could do worse than learn that.
On the .Net side, Ninject is probably the most interesting, on the Java side, I would say check out Google Guice. That being said, DI is DI, and they all more or less do the same thing. The differences are mostly in how they are configured.
Google Guice is very good - unless you really need it, there are no .xml configuration files - everything is done via annotations, and in an ideal world you can avoid setter methods, injecting your dependencies via the constructor.
I'd suggest JBoss Seam. It has a very different dependency injection model than Spring. Seam's DI is bidirectional and able to inject values at every stage in an object's life (not just during initialization).
It's certainly not a good for everything, but if your looking to try different things in DI, this is interesting.
Look at Seam's home page.
So in the wide world of software you feel the need to learn what is 'assumed plumbing' rather than expand your base? You just use IoC. It's not even optional for anyone serious. This is going on like a decade now.
Go master Functional Programming in say F#. Master the new IObserver and related work coming in .NET 4.0 as the conceptual pairing to IEnumerable. Write a domain specific language for your domain of choice. Create New abstractions, don't simply relearn old ones.