I am developing a web application using struts2 EJB3(Service/business layer) and Hibernate. I am using Wildfly 10 as a server. Struts is at presentation later, EJB3 at business layer along with simple java classes as Service layer and hibernate is used in persistence later.
Now in one of my action classes I have passed the modal object to the service layer(Simple java classes). Now when I created the EAR and tried to deploy it on the WIldfly. WIldfly refused to start. Then I realised that my ejb module is not able to find the classes of web module. So now I have two ways to resolve this problem:-
1) Either include my web classes in EJB jar:- I think it will completely kill the layered architecture and decoupling of presentation layer and service layer.
2) Or map the modal classes to some other modal classes present in service layer:- It will require to create redundant POJO classes in service layer as well.
Not really know what should I do in this case and if someboddy can suggest me with some better layering structure
There are serveral ways you can architect your models for each layer but at the end of the day, it depends on how much you wish to couple each layer with one another.
Obviously the most granular and cleanest solution is to allow each layer to have its own models and to map accordingly at each integration point.
Persistence models, e.g. your #Entity classes
Domain models, e.g. those your service tier takes as input and returns as output.
View models, e.g. those your presentation tier takes as input and returns as output.
The advantage of such a distinction is that it allows the models at each level to morph over time without a significant impact to the tiers above it. In other words, adding a new field or changing something with your persistence model doesn't necessarily mean your domain models must change, but just the mapping code between them.
Obviously there are a number of sources on the internet which advocate simply reusing your #Entity classes as the model at each tier and for simple applications, that's definitely acceptable. But in more complex, scalable solutions that eventually becomes a liability.
Sometimes it's acceptable to collapse (1) and (2) into a single model, the #Entity and then use special view models for rendering so at least your view code isn't impacted when you make model changes over-time, but I typically err on the side of using a different model for all three tiers in many cases for complex applications.
Related
I have a problem with the domain-driven design architecture. Everything looks nice until I try to use REST. I should use the DTO instead of the entity on the frontend.
My architecture looks like:
My question is :
Should I use the web module and stick to it in the DTO? Is it the correct approach?
Domain Driver Design (DDD) approach was introduced on 2003, by a book with that name.
REST was initiated from the a Doctoral Dissertation named Architectural styles and the design of network-based software architectures that was only published on 2000.
It took some time for REST to spread, establish, and becoming popular. It probably reached "world-level popularity" roughly around ~2005-2008.
DDD referred mostly to isolated monolithic systems, or at least didn't cover aspects of cross system communication.
Therefore, even if you work "according to DDD", you will have to make your decisions - how to handle these aspects.
Reference: list of patterns introduce in the DDD book, with their relations:
You should see REST as just one of many "ports" allowing to reach your application layer services. REST, RPC, Websocket, etc. services would adapt & map input to application layer calls and vice-versa. At each service boundary you still have the flexibility to adapt responses, which does not have to have a 1-1 mapping with application service method responses, but could.
According to Implementing Domain Driven Design book by Vaughn Vernon, DTOs live in the application layer.
Ideally, the Domain models should be created by factories. So the factories can accept DTO and return an instance of the Domain model. Or you could use Builder pattern that accept DTO(s) to create the Domain model. This way you're domain model is kept clean from DTO and the Application layer in your architecture diagram should accept DTO(s) as parameters.
In your diagram, I am not sure what is the purpose of Application layer. Since what we call application should be the domain models.
Consider the following example.
There is a server application that has three layers. The service layer that is exposed to the clients, the database layer that is used for persistence and the business layer that calculates something.
The application serves three different types of data. Users, Payments and Worktimes.
How should I package my application?
Package by layer:
foo.bar.service
UserService.class
PaymentsService.class
WorktimeService.class
foo.bar.persistence
UserPersistenceService.class
PaymentPersistenceService.class
WorktimePersistenceService.class
foo.bar.business
PaymentCalculator.class
Or package by type:
foo.bar.user
UserService.class
UserPersistenceService.class
foo.bar.payment
PaymentService.class
PaymentsPersistenceService.class
PaymentCalculator.class
foo.bar.worktime
WorktimeService.class
WorktimePersistenceService.class
I guess the first example could become confusing if the application grows and more and more logic is implemented. However, it appears to be easier to find the right place when the task is to "extend the persistent service layer to do something fancy".
The second example can be easier extended without flooding packages with millions of classes.
Is there any best practice to choose between them? Or do you guys have any other idea of a package structure.
As far as I am concerned I would package by layer AND type :
foo.bar.service.user.UserService
foo.bar.persistence.user.UserPersistence
And so on
For most of my projects I use maven and some multi modules :
Domain Model (Model Objects)
Persistence
Service
Applications
With this way, you could get different jars (or not if you have got only a simple project) and it is easier to retrieve the good place to extend/modify the existing sources.
What is more important for your application?
Do you deploy the layers/types to different machines (or might want to do so in the future)?
Do different people work on different layers/types?
If so use layers/types to seperate packages.
If your application is a little larger, you probably want to use both, resulting in packages like
foo.bar.<layer>.<type>
or
foo.bar.<type>.<layer>
Usually there is a model package in which you put the types (Users, Payments and Worktimes in your example).
Next to the model package there are layer packages like presentation and service (I normally nest data access layers within the service package to encourage these layers to only be used from service implementations but that's up to you).
If the project is a bit bigger I split out the service layer into a separate module. If it is bigger still (or the domain model is large and complex) I also move the model package into a separate module, resulting in a three-module project: model, service and presentation.
If there are also multiple presentation channels (e.g. web application, REST service and dekstop client app) these can also be split out into separate modules.
I am a S/W developer working on a Java web application.
I have very limited knowledge of Java and want to understand my application architecture from a very high level in simple terms. Being a developer, I do not completely understand the big picture.
Can anyone help me understand this?
Each layer represents a place where some problems are solved is similar way, often using some particular libraries or frameworks. In trying to understand this work your way down through the layers. BUT, note that each layer hides the details underneath, you don't need to understand the details of lower layers in order to understand one layer.
So the Struts piece is dealing with the User-Interface related issues of understanding user requests choosing some business logic to invoke and choosing how to display the results back to the user. It doesn't concern itself with how the business logic works, that's the job of the next layer down.
By Business Logic I mean the Java (or other language) code that expresses the realities of a the customer's business. For example in a retail application we might need to work out discounts for particular volumes of orders. So the UI layer wants to display the price for a customer's order. It doesn't have any discount logic itself, instead it says to the business logic layer "Customer X is order N widgets and M zettuls, when can we supply and how much shall we charge" and the business logic figures out the pricing for this customer, which might depend on all sorts of things such as the status of the customer, the number things we have in stock, the size of the order and so on. The UI just gets an answer £450, to be delivered 16th September, and displays it.
That leads to questions such as "why separate the business logic to its own layer?" There are several possible reasons:
The business logic might be used by some completely different UI as well
It pre-exists, from some older system
Our brains are too small to think about UI and Business Logic at the same time
We have different teams working on UI and BL - different skills are needed
This same way of thinking follows down the layers. Th important thing when thinking about each layer is to try to focus on the role of the layer and treat the other layers as black-boxes. Our brains tend to be too small to think about the whole thing at the same time. I can almost feel myself changing mode as I shift between the layers - take off my UI head, put on my persistence head.
There's plenty of material "out there" about each layer. Suggest you start by reading up about one of them and ask specific questions if you get stuck.
Looks like a standard "enterprisy" application to me.
Interface
This app. is primarily intended to be used via web browsers by humans. This interface or UI layer (in a broad sense) is build using the MVC framework Struts. If you don't know MVC, then it's a good idea to read up on this term.
The app. also exposes web service interface, which is intended to be used by non-humans (other applications or scripts).
So, 2 kinds of interface is provided.
Business logic
Request coming from the 2 interfaces noted above, ultimately talk to the lower half (App. tier) to get some real job done. The actual process (calculating stuff, storing stuff and what not) happens here. Note also that this tier also talks to external systems (via Service Gateway) in order to complete the requests.
The reason they separated the system like this can vary. If it's a very simple, small app. then it doesn't pay off to have these abstractions, so it's probably a quite complex system. Maybe the app. tier is some legacy app. and they wanted to put some better UI on top of it. Maybe the app. tier and the web tier happened to use different technology stack. Or perhaps the app. tier is used by many other external systems. It also makes updating each services/replacing each services etc. easier, so maybe they are anticipating that. Anyways, it looks like a very common SOA type of design.
Not sure what else you might want to know. I see that the designer intends to use distributed cache in both tiers. All in all, it's a very common type of system integration diagram.
App Tier - Where the basic application logic resides (think of a basic console-only program).
Database - MySQL, Oracle... server
DOs - Short for Domain Objects. If anemic usually limited to getters/setters and can be synonymous with Entities (#Entity).
Data Access Objects - Objects using DAO pattern to fetch domain objects from the database. Could be considered equivalent as DAL (Data Access Layer) although this might not fit here. Usually uses a persistence/mapping framework such as Hibernate or iBatis.
Domain Model - Where Domain (domain being what has been studied/analyzed from requirements) Classes are packaged and associated (one-to-one, many-to-one, ...). Sometimes there are even composited in other container classes.
Core Application Services - Groups Services classes which could be equated to the Business Logic Layer (BLL). Biz services handle the Domain Model, Application Services are relative to the Application (methods don't manipulated Domain) and not sure what System Services are supposed to do. I'm also not sure what the distinction between Core and the Application Service block is.
Facade/Interface - This is where all the communication is done with other Tiers. It helps to fully understand interfaces and the Facade pattern.
TOs: Transfer Objects. Related to Domain Objects and used for transferring as the name implies.
Web Tier - All the logic added to make the application accessible from the Web.
Business Delegate: Block using delegation pattern? Here it apparently plays the middle man between Application facade and the Presentation Tier using TOs.
Model: Notion relative to the MVC pattern and variants. With JSF I know that beans are usually linked to JSPs. This model is to be distinguished from the Domain Model. It is created for the purposes of presentation and might contain information that has nothing to do with the data being manipulated in the application tier and is specific to the web tier.
View: Notion relative to the MVC pattern and variants. JSPs represent individual pages and use their own markup.
Session: Look up theory on sessions (necessary as HTTP is stateless).
ApplicationContext: Groups instances/settings that can be pulled into from anywhere. Often associated in the Java world with the Spring framework. To not be confused with UglyGlobalVar/singletons.
Front controller: Could be considered as equivalent to Controller of MVC although the Front Controller pattern appears to be more specific. Servlets are considered as controllers as they handle communication (GET, POST...) and coordinate the model/view. Not familiar with Struts but imagine that the framework implements classes to represent user actions.
Presentation Tier: Simply all of the logic used for outside presentation.
Filters: Can be used to filter requests, for example to redirect a request to a login page.
Feel free to add/correct this description.
I am trying to use the DAO pattern in my multiple web app projects. I have three different web applications and they share two different databases. Each databases have number of tables.
Now I am wondering how I can make my program modular by using best practice. I am thinking of making:
DAO project which have two factory class for each database, DAO interfaces for each tables and DTO for each tables.
Then in each web app project I am planning to write implementation code for DAO interface and necessary utility class for getting and closing the connections.
Is this approach good? The doubt/problem i am having is with this design if I am going to ship any one of the project I have to ship DAO project also but that will contain unnecessary info about other databases.
Or will it be good to attach all necessary DAO in web app itself? If so then I have to write same DAO ode for each web app.
Hope anyone can provide me the clear path for this DB connection using DAO pattern.
In general, you're headed in the right direction by separating your concerns.
You mention the multiple web apps rely on the two databases. Does each web app rely on both databases? If so, I'd consider creating a single DAO project to encapsulate all the data access logic.
If it's more a mix and match (web app a uses db a, web app b uses db b, web app c uses a and b), I'd consider having two DAO projects, one per database, unless there's a lot of combined logic - that is, when an app uses both databases, it's doing joins between them [yes, I have had projects that do this].
I'd also recommend looking at an Object/Relational Mapping (ORM) framework such as Hibernate and/or a Dependency Injection framework such as Spring, which can help simplify the process of separating the various projects and then using them together.
You're clearly planning a pretty ambitious project, so taking advantage of existing frameworks to minimize recreating the wheel will let you focus on your specific problem domain.
Use JPA to access DB. If not possible then use JdbcTemplate (Spring)
EntityManager (JPA) is a kind of a DAO
DAO only where it makes sense (e.g. complex, reusable logic using an EntityManager)
Use pooled connections/ DataSources
DTO are usually only needed if your objects need to leave the JVM (e.g. remote EJB services, web services,...)
use EJBs for container-managed transactions
consider the Gateway pattern (a stateful session bean and an extended persistence context, see "Real World Java EE Patterns – Rethinking Best Practices" by Adam Bien) and just return the attached entity.
I started experimenting with Spring Roo just recently. It does a very nice job helping one build a domain model with integrated persistence rather quickly. As it adds persistence functionality in aspects, I started think about the following question:
Roo adds finders (load an instance of a class from the database which meets variable criteria) in an aspect to the actual class/entity. In DDD this is IMHO the responsibility of repositories. Repositories are explicit classes which show up in the design. Of course as an aspect the repository functionality is hidden in an entity and is pretty much invisible.
So here is the question: Is an aspect a real substitute for a explicit repository class? Are there any downsides to the Roo AOP approach?
Adding finders to your domain classes feels more natural from a user's point of view but it mingles your layers. Grails uses the same approach by adding static finder*() save(), ... methods.
Apart from the aestetics it might have practical drawbacks when not used in web application setting:
Your domain classes are now tied to your database. If you transfer these objects to rich clients via RMI or HttpInvoker the client cannot and often may not use the find* methods because there is no session / database connection available on the client.
I generally prefer allowing domain classes to reference service layer interfaces to prevent an anemic domain model (http://martinfowler.com/bliki/AnemicDomainModel.html). This has its own set of drawbacks but at least provides a clear boundary. On the client the concrete implementation behind a service interface can then just proxy all method calls to the server (or just use a synamic proxy with spring remoting or sth similar).
So to answer your question: It might be a substitute but you should be aware of the possible negative consequences which make your domain classes (i.e. your core business logic) less portable between systems.
This depends on how complicated your applications persistence layer is and how much control you have over it. If your application is simple enough to be implemented via JPA, then it all could be handled via Roo aspects. However if you are mapping legacy tables or need advanced DB stuff, then you may find yourself in a situation where Spring-JDBC is the only way out and in these cases a repository/dao model may still be useful.
I consider it logical inconsistent (and a break of layer responsibility) to be mixing two persistence models and so as most of my applications requires such advanced DB constructs I stick strictly with a repository model.
I think adding repository methods to domain objects is bad design. The right place would be static methods in the domain class. But domain objects and their management are two different things that should be separated. I would prefer domain objects and repositories.
I guess the motivation was to achieve something Rails/Grails like with Java.