I have to create 2 projects. For this I will user Spring,JPA,JSF and Maven. My projects will be structures on a 3 layer architecture, so I will have view,service and DAO layers. The persistence layer will be provided by hibernate with JPA2.0.
The problem is that this two projects will share a big part of code, basically both projects operates on the same database, and will share the majority of entities, DAO`s and maybe even services.
After I googled a little bit i found that this task cand be achieved with a multi module maven project. So I have created a multimodule maven projects which was composed of:
- core package (that will contain all the common classes),
- internal webApp (which will be accessed by internal users)
- external website (which will be accessed by external customers).
The problem that i encountered here is persitence.xml location, because if i put that file to core package i cannot include the entities from other projects. If i put the file inside projects i can refer the core entities with inside persitence.xml, but some functionality that i want to share, ie:
public abstract class GenericDaoImpl<T> implements GenericDao<T> {
#PersistenceContext(type = PersistenceContextType.TRANSACTION,unitName="CCPU")
protected EntityManager em;
wont work anymore because eclipse is "screaming" that there is no persistence unit with name CCPU, because the persistence.xml file is no longer in this project.
First of all, is this the right approach for this kind of problem?
The last but not the least, where should i put the persistence file in order to be able to combine entities from all 3 sub projects ?
I have the same situation: two webapps with common domain objects, but all my entities are located in "domain" module. Webapps are like "front-end clients" for "domain" back-end module.
If you want to locate webapp-specific entities in appropriate projects try to delete "em" field from GenericDaoImpl and pass it as parameter to all methods.
Related
Experts,
I need some expert advice on how to approach the below use case in spring boot.
I need to have a maven multi-module approach to my project.
I need to have a single jar as output of the final build process.
There are to be common modules for controllers, data access and other functionality
Other modules are to be created based on functionality domain for eg a module for Payroll, a module for Admin etc etc.
Each domain functional module will then have their own controllers extending the common controller, exception handler and so on.
Each module will also have its own set of thyme leaf pages.
The reason for following such an approach is we have development in phases and we will be rolling out based on functional modules.
Here are the issues that I can sense using this approach.
Where do I add the spring web dependency? If I add to the parent pom - it gets replicated across the children and there will be port conflict issues as each module loads. the same issue will also be there the moment I add it to two child modules.
How do I build the fat jar which has all the jars from all modules and works as the final deployment?
All the text that I read i can't see anything even close to what I am trying to achieve.
AD1. They will not unless you are trying to setup independent application context in each module. Of course you can do that(it might be complicated but I believe it's achievable), but for me it's an overkill. Personally I think it's better to have one application context and rely on scanning components that are present in classpath.
AD2. The structure in maven might be a little bit complicated and overwhelming at first glance but it makes sense. Here's how I see it:
Create a parent module that will aggregate each module in project and will declare library/plugin dependencies for submodules.
Create 1-N shared submodules that will be used in other modules. With come common logic, utils, etc.
Create 1-N submodules that will be handling your business logic
Create an application submodule that creates application context and loads configuration and components from classpath
Create a submodule that will be responsible for packaging process, either to war, jar, uber-jar or whatever else you desire. Maven jar plugin should do that for you. For executable uber-jar, you have dedicated tool from spring.
Now you can choose three ways(these ways I know) of loading your modules.
1. Include some modules in maven build based on the build configuration via maven profiles and let spring IoC container load all the components he finds in the classpath
2. Include all of the modules in maven build and load them depending on spring active profiles - you can think about it as of feature flag. You annotate your components or configuration class with #Profile("XYZ") telling spring IoC container whether to instantiate component or not. You will need (most flexible solution) to provide a property file which tells spring which profiles are active and thus which modules should be loaded
3. Mix of these two above.
Solution 1 pros:
build is faster (modules that are not included will be skipped during build)
final build file is light (modules that are not included are... not included ;))
nobody can run module that is not present
Solution 1 contras:
project descriptor in maven may explode as you might have many different profiles
Solution 2 pros:
it's fairly easy and fun to maintain modules from code
less mess in project descriptor
Solution 2 contras:
somebody can run module that is not intended to be run as it's present in classpath, but just excluded during runtime via spring active profiles
final build file might be overweight - unused code is still present in code
build might take longer - unused code will be compiled
Summary:
It's not easy to build well structured project from scratch. It's much more easier to create a monolith and then split it into modules. It's because if you already created a project, you've probably already identified all the domains and relations between them.
Over past 8 years of using maven, I honestly and strongly recommend using gradle as it's far more flexible than maven. Maven is really great tool, but when it comes to weird customization it often fails as it's build capabilities rely on plugins. You can't write a piece of code on the fly to perform some custom build behaviour while buidling your project, you must have a dedicated plugin for doing that. If such plugin exists it's fine, if it's not you will probably end up writing your own and handling its shipment, so anyone in your company can easily perform project build.
I hope it helps. Have fun ;)
I have created Business and DataAccess Layer for my web project using dotnet core.
I have added Data access reference in Business layer and referenced the business layer in UI (web project) layer.
I seen, I am able to access my Data access layer from my UI (web) project. I am really wondering, It can lead to violation of any application design.
Appreciate help, if anybody come across this and how to restrict access to data access layer from UI.
Yes, an indirect dependency is a dependency too.
And your toplevel (MVC) project has to reference everything, direct or indirect, in order to get all modules loaded. And to set up the dependency injection.
You can get better separation by introducing an interfaces layer in a separate project. For example IBusinessClass and IDataAccessClass.
That works for everything but the main project so if you want this particular separation from your example, move your Controllers to a separate project and depend that on the IBusiness interfaces only. Though I'm not sure how that works with MVC's conventions.
My question is really simple, thought I haven't found anything online related to it.
Is the maven-surefire-plugin able to have a dependency excluded but at class level and not at group-id:artifact-id level?
My problem:
I have a web project, related to a plain java project A. This A project contains hundred of classes that do a variety of things (connects to the database, sends web services, calculates stuff, manages the logs, context, sessions, etc...) and the dependency is quite strong. Since all unit testing on the web project will be hard to do without this A project I need to have it as a dependency even for the testing. But of course I cannot use some of the classes in there (mainly the DB connection and the session stuff). So I thought that instead of mocking them (because there are like a few dozens of them and I want to do different things with the functions (like writing to a file that it tried to connect or read the "session" from an xml file)) I can create a A-test project and include the classes I want from this new project and exclude the classes I don't need from the A project.
I know I can copy/paste all the project and then replace the classes I want, but if something changes in project A, I then have to maintain it in A-test (and I am very lazy and don't like to work twice). I thought that maybe I could have some kind of plugin in maven that will copy all the other classes (the one I am not... let say 'overriding'), every time. But it seems a waste of time if I just can tell the plugin which classes to use during the test step.
Thanks for your help!
We want to create a spring MVC project using maven. We want to use just one project and, under it, have multiple sub-projects
What would be a good directory/package structure for the project for example
com
company
subproject_1
controller
doa
service
entity
subproject_2
controller
dao
service
entity
or all files of sub projects in one project
com
company
controller
all controllers of all sub projects
doa
all dao of all sub projects
service
entity
depending on the experience which project structure would be maintainable if the project increases and sub projects keeps adding on
or suggestion of any other package structure?
also what is the naming standard used for directory
is it entity or domain? doa or persistence?
Why not following a multi-module project structure to group your sub-projects? It's a good coding practise widely adopted, recognised and easily manageable. Have a look at this example.
As far as the naming conventions goes that's personal preference but it's good idea to clearly maintain in package structure the different layers as you are saying from botton-top approach: the dao level, the domain, the service layer, the controllers and finally the view.
Try to use the add to working set option.
Create maven multimodule project.
In each project two options:
package by feature
package by layer
these options discussed here: http://www.javapractices.com/topic/TopicAction.do?Id=205
My personal approach is to create in each maven module project packages by feature and some "util" packages used by "feature" packages.
(I had a hard time titling the question so feel free to suggest edits)
Here's the situation: we have just started building a system which is comprised of two integrated MVC 3 web applications running on Azure with a shared AzureSQL database. There are many reasons for running two apps instead of one and I'd rather not get into that...
Originally, database was created code-first from the MVC application "A". 75% of entities from all created will be relevant to application "B" plus application "B" will need a few entities specific to it.
Currently, the entities-defining classes have been extracted into a class library so within the application "A" solution to allow for reuse in application "B". But I am still unsure how to go about adding entities required for application "B"...
The question is: what is the best way to manage the database development/management in this situation? Specifically, where should the definition of entities be? Should we just have a separate db project defining the database and work db-first? (with this option being my preferred at this stage).
Since both of the devs (me and the other dev) working on this are new to MVC and EF, any advice would be much appreciated.
Without seeing what you have its not entirely mapping here in my brain - but I think I may have an idea on this.
Can you create an additional projects containing your models (data access layer) that has your entity framework edmx (or code first) and poco templates installed. This project will be shared by both applications - ie both projects get this assembly and both have the ef connect string in their web.configs.
Another approach is to put all code first into a single project (whatever.domain, whatever.models) etc. Your mapping code then goes into your DataAccess project
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Conventions.Remove();
modelBuilder.Configurations.Add(new CustomerMap());
...
}
You now have shared poco classes and a single data access layer.
Some treat their poco classes as their domain objects (theres no problem with this) and their business logic goes in the poco classes. This is fine as long as your poco objects themselves remain persistent ignorant and ideally you don't want to reference implementation specific components in your poco classes. For a good writeup here see:
POCO - if POCO means pure .net class with only properties, where i can write validations in MVC
Personally I like db first and then reverse engineer it using the EF power tools to have a code first model as if you ever want to integration test it, you can simply create the db for your integration tests and remove it when done.