I have two spring applications, the 1st app communicates with hibernate and the 2nd project communicates with elasticsearch, the data added by first project, then replicated from mysql to elasticsearch.
This data on elastic will be used in the 2nd spring application.
So, my question is the entities in first project for example have translation objects and it will be different objects each has details in one language, then we create a common project that contains these entities that will be used as maven dependency in both apps.
Does this way is correct or moving these entities into every project to do the differences since entities won't be exactly the same in both projects
If the classes are not exactly the same it doesn't make sense to share.
Sharing often results in a tight coupling between components and hinders the independent evolution of the components.
Related
We are beginning the process of re-architecting the systems within our company.
One of the key components of the work is a new data model which better meets our requirements.
A major part of the initial phase of the work is to design and build a data migration tool.
This will take data from one or more existing systems and migrate it to the new model.
Some requirements:
Transformation of data to the new model
Enrichment of data, with default values or according to business rules
Integration with existing systems to pull data
Integration with Salesforce CRM which is being introduced into the company.
Logging and notification about failures
Within the Spring world, which is the best Spring project to use as the underlying framework for such a data migration tool?
My initial thoughts are to look at implementing the tool using Spring Integration.
This would:
Through the XML or DSL, allow for the high level data flow to be seen, understood, and edited (possibly using a visual tool such as a STS plugin). Being able to view the high level flow in such a way is a big advantage.
Connectors to work with different data sources.
Transformers components to be built to migrate data formats.
Routers to route the data in the new model to endpoints which connect with systems.
However, are there other Spring projects, such as Spring Data or Spring Batch, which are a better match for the requirements?
Very much appreciate feedback and ideas.
I would certainly start with spring-integration which exposes bare bones implementation for Enterprise Integration Patterns which are at the core of most/all of your requirements listed.
It is also an exceptionally great problem modelling tool which helps you better understand the problem and then envision its implementation in one cohesive integration flow
Later on, once you have a clear understanding of how things are working it would be extremely simple to take it to the next level by introducing the "other frameworks" you mentioned/tagged adding #spring-cloud-data-flow and #spring-cloud-stream.
Overall this question is rather broad, so consider following the above pointers and get started and raise more concrete questions.
as I mentioned I want to implement a backup/snapshot feature for my web app.
As for details, imagine each User has several Projects which has several Components which also has several Subcomponents. Those are the entities that I want to backup apart from User.
The goal that I want to achieve is that user may save the current state as a snapshot and later if he doesn't like the new configuration, can easily turn back to his save and there can be multiple snapshots. Those snapshots has to be read only.
I'm asking for a design architecture or style or any kind of idea to implement. That's why I didn't put my entities here.
Thanks, beforehand!
I have some similar versioning in a project where I manage that in a service by simply introduced another entity. In your case that would be a ProjectVersion and the Project has a list (OneToMany) of these versions and additionally a ManyToOne (or OneToOne) relation to one ProjectVersion called master. The Project itself has no more fields.
A few days ago I stumbled across #Version from java persistence API (not the spring one) and this annotation should help to automatically increase and manage a version value in the entity during updates. But I haven’t tested it myself.
We are creating a web based application using, JSF (Primefaces as presentation library) and Spring Data JPA for data access tier. And the project is Spring Boot enabled.
The project is divided into multiple modules (according to tiers), and one of them is the presentation tier.
Do you suggest creating a dependency from presentation tier to Spring Data (so have access to PageRequest and Slice and ... classes) or not?
Otherwise we shall re-implement these classes in this tier and convert them to Spring Data classes, which seems some how verbose.
Do you suggest creating a dependency from presentation tier to Spring Data (so have access to PageRequest and Slice and ... classes) or not?
Every decision you make will have it's Pros and Cons and it really depends on your specific situation if this is a problem or not.
I see the following things in favor of a dependency:
reuse of PageRequest and similar classes. They represent concepts that are needed when working with persistence but aren't really persistence specific. Therefore there is really no point in duplicating them.
On the other hand, Spring Data contains many classes that don't have any business in a presentation layer. For example, those dealing with creating repositories.
Your task is to determine if the risk/damage of having those classes around is bigger than the benefit of having PageRequest and co available.
With all teams and projects I worked with so far I'd opt for just having a dependency.
Here is why:
The domain has a dependency on JPA and Spring Data anyway. So by depending on the domain-layer, you get a transient dependency, no matter if you want or not.
The persistence specific classes inside Spring Data are so specific that I never experienced anybody trying to use them directly.
Note that especially the first point assumes that you are not copying over your JPA entities in separate transport objects, which would kind of negate the benefits of JPA.
Please ignore English grammar.
For Learning purpose I want to create a microservice project in Spring and I download some sample project and now I have some very basic
idea of microservices. But I am confused how I start my own project.
I want to implement the following simple use case.
In my database I have three table
Product,
ProductStock
and Order and I want to write microservice for each table.
Product microservice will have end point for crud operation.
ProductStock microservice will only have update stock and check stock end point.
Order microservice will only have posting order operation.
I create a multi module maven project and now I have following question.
1: Is creating multi module maven project is the only way to create microservices project.
2: I am using Hibernate so in which module(microservice) I create model classes. I need model classes in every module(microservice).
(Model classes are Product, ProductStock and Order).
3: Where I set hibernate confiuration.
Even if this question is way too broad, i'll try to answer your question as good as i can:
A multimodule project is not the only way (and i would even say, not a recommended way for different services). Usually you have completely separated Maven projects for each service.
Every service has to have its own data model and entity classes. Services should never share any entities, and should not access the same databases/schemas. They can use the same database server with different schemas.
In every service, which uses Hibernate.
The microservice architecture is not a trivial area so I would suggest to you that you start with some theory first. One of the books which is often referred here and there is Building Microservices By Sam Neuman. I highly recommend reading it or at least a part of it. This is the theoretical part.
Then for some hands on experiences you may want to clone/fork the PiggyMetrics project. This is an educational project but at the same time it contains quite a lot of patterns and advanced stuff.
After that you will be able to answer your own questions yourself, albeit there will be much more to ask ;-)
Good luck!
(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.