I want to retrieve a product from my database. A product is made up of data from several different tables.
Is it best to create a facade that will talk to multiple entities in order to pull together all the info needed to make a product and should the facade marshal the object or is there another way to do this?
I was thinking the method in the facade would be getProduct() and this method would use multiple entities?
Thanks
Why not use a product Entity and have JPA do it all for you? An entity can span multiple tables, and your product Entity can itself have references to other entities where it makes sense. Your application can make accessors within the Product class to expose the referenced entities or just return data from those references as needed.
Related
I have a JPA entity, which I want to store exactly with the same fields in two different tables for different purposes.
I assumed, that there is a possibility to set which table to actually store data in Spring Data Jpa repository, but couldn't find how to do it.
Is it possible?
If not, what is the best way to achieve my goal with spring data jpa and without copying the entity class?
You may want to define an abstract class for your entity using #MappedSuperclass annotation. You can specify your field mappings in this class. Then have two separate entity classes which inherits your abstract class and each of those two can map to their own table.
I am getting data with 50 fields. How to map into two tables in jpa, in which I required only three fields and rest of fields I need to only pass to downstream?
This is for a new spring data jpa, running H2 db project. In the past, I’ve tried to map all 50 fields in one entity table. But I require only 3 essential fields from those 50 fields to process of last 5000 records from db.
#Entity
class SingleCustomer{
//ID field
// 3 fields only these fields I am using to process my data from db
//47 fields just to pass to another service without any process
}
To improve performance of my application which approach I should take?
Are there any other ways to improve application performance like split into two entities and join on one to one when needs to send another service.
As you said you can split all the fields into two entities and join on one-to-one relationShip. But you should notice that field with one-to-one relationShip is loaded eagerly by default, you should mark it as lazy-loaded to improve performance.
Using a separate entity for fields you don't need together with a #OneToOne association is one way of doing that, as #Lebecca pointed out.
However, if you'd rather keep all the properties in one entity, you could turn on Hibernate bytecode enhancement, which enables support for #Basic(fetch = LAZY). If you want, you should also be able to combine such an approach with using a #SecondaryTable to store the properties you don't usually need.
See here for more info, including info on how to fine-tune the lazy loading behavior with enhancement enabled.
I have two table called table_1 and table_2, and on each table I have to perform some insert, delete and update operation.
Can anyone please let me know that should I create two different (Data access object) implementation or should I have only one? and whats the advantage or disadvantage in both the approaches.
If rows can be inserted/updated/deleted independently in both the tables then yes, you should go ahead with separate DAO classes. Below are the advantages:
It promotes separation of concerns design pattern.
Spring data jpa also uses the same design, it works on one Repository per entity (table in our case)
If you have any functionality that requires querying both table 1 and table2 then it should ideally go into service layer and call two DAOs. Also, if you have any foreign key relationships between these tables, you can map it using #OneToMany, #ManyToMany etc annotations.
I am using MVC pattern in my web application. In which I have three layers
Control Layer
Manager Layer
Dao Layer
And I am using DTOs from control layer to manger and then to Dao layer and same as opposite.
My question is that what is the main purpose of DTO?
Can I use DTOs to map our relational database table or should I go with 'Bean'?
If I use DTOs between layers then how can I represent a database table in an object because DTOs among layers can contain properties which are not related to the database table.
There is no problem in using DTOs and map them to your database tables. But you'll have to do the mapping by yourself (using JDBC, Spring JDBC, etc).
Another option is to use an ORM to do the mapping of your DTOs to database. You can even create properties that are not mapped to your tables. Take a look at JPA.
The choice between those two options is something personal. The first will be more laborous at first, while the second option have a bigger learning curve. If you are well versed into SQL, I would go with JDBC.
My question is that what is the main
purpose of DTO?
The main purpose of a DTO is to transmit data between two layers. It has no real functionality other than to act as a basket for shipping data.
That's why they call it a Data Transfer Object.
Can i use DTO's to map our relational
database table or should i go with
'Bean'?
Whether you decide to use JavaBean formatted accessors or your own accessors really doesn't matter with a DTO. Both sides of the transfer must be in agreement; but, if you have a setName(...) setter or a name(...) setter it will not affect functionality.
Although it may not matter in a functionality sense, it is best to stick to established naming conventions for ease of revisiting the code and lack of confusion when training new maintainers. Also, a few libraries might assume you are using bean conventions (or require them). If you are uncertain, best to stick with standard JavaBean conventions, as your new conventions are probably not as tested (or as formal).
If i use DTO's between layers then how
can i represent a database table in
object because DTO's among layers can
contain properties which are not
related to database table.
DTOs have nothing to do with database tables. Don't make your DTO look like your database table unless it's the most natural thing to do.
The main purpose of DTO's is to reduce the overhead when transferring data across layers.
If you didnt have a DTO, what you would have is a class containing data as well as logic which would be getting passed across layers. Using DTO's ensures that you pass only what is needed i.e the data across layers.
Definitely, you do have the option of mapping your DTO's to your database tables and having the bean design which more closely represents the domain objects.
That is one way of doing it.
Conversely, depending on your database design, your DTO's could be more in line with your actual business entities - just without the logic
My question is that what is the main
purpose of DTO?
Like the expansion (Data Transfer Object) implies, DTOs are meant to transfer structured data across various tiers. DTOs enable you to decouple the protocol specific implementations that represent data, so that data from different sources can be abstracted before communication across tiers.
For example, DTOs will allow you to decouple the data present in a HttpServletRequest object from its internal storage, so that you can send the data to a service in the business logic layer. The same applies for DTOs used to abstract the results obtained from a SQL query and residing in a ResultSet object. In short, DTOs allow you to transmit data without holding onto the source - you can forget about the HTTP response and the JDBC connections, while you work on the data.
Can i use DTO's to map our relational
database table or should i go with
'Bean'?
You can adopt the second approach of using Beans. In fact, with JPA you do not require your DTOs at all. The JPA managed beans themselves represent data in various tables, and can be de-linked from the database state, so that you can use them for data transmission.
If i use DTO's between layers then how
can i represent a database table in
object because DTO's among layers can
contain properties which are not
related to database table.
That depends on how you want to couple the DTO with the database table. It is preferable to have a one-to-one mapping between the DTO and the database table, and choose another DTO for the purpose of transmitting properties not related to the table. After all, DTOs like every other object should have a single responsibility. If the responsibility is to reflect a database table, then it should contain other "irrelevant" properties.
To extend the recommendation of using JPA in this context, it is poor design to have unrelated attributes in a JPA entity, especially when that unrelated attribute should be marked as transient and adds no value to the behavior of the entity.
I'm looking for feedback on the Data Access Object design pattern and using it when you have to access data across multiple tables. It seems like that pattern, which has a DAO for each table along with a Data Transfer Object (DTO) that represents a single row, isn't too useful for when dealing with data from multiple tables. I was thinking about creating a composite DAO and corresponding DTO that would return the result of, let's say performing a join on two tables. This way I can use SQL to grab all the data instead of first grabbing data from one using one DAO and than the second table using the second DAO, and than composing them together in Java.
Is there a better solution? And no, I'm not able to move to Hibernate or another ORM tool at the moment. Just straight JDBC for this project.
I would agree with your approach. My DAOs tend to be aligned more at the object level, rather than from a DB Table perspective. I may manage more than one object through a DAO, but they will very likely be closely related. There is no reason not to have SQL accessing two tables living in one DAO.
And for the record, I have banished the acronym DTO from my vocabulary and code.
Ideally, how you store your data in a database, and then how you access them, should be derived from the nature of the relationship among the domain entities in your domain model. That is, Relational Model should follow from Domain Model. For example, if you have two entities, say, User and Address.
Scenario #1: Address are never accessed independently, they are always an attribute of User.
In this case, Address is a Value Object and User is an Entity, and there are guides on how to store this relationship. One way is to store Address attributes of Address alongside of attributes of User, in a single table. In this case, UserDao will handle both objects.
Scenario #2: Address can be associated to a User, but also can be separate on its own, an entity.
In this case, an approach different from the first one is needed. You may have a separate DAO and table for the Address type.
My point is, that more often this important idea is ignored that Domain Model should be the core of the application, driving other layers.
For instance, if your domain model is properly define and you are well aware of the type of entities you have and the relationship among them, then your persistence (relational tables and their relationships, your DAOs, etc) will evolve as a very logical consequence of what you have in the domain model.
In other words, if you spend some time studying your model, you will be able to trace your problem in determining how to organize your DAOs to a place in the domain model. If you can clearly define the type of the objects and the nature of relationship among them in the domain model, it will, help you resolve your problem in DAL layer.