Learn about the implementation of a simple asynchronous processing use case in Rails utilizing a sample application into which I have integrated the code.
Thanks, Aleksey. And also for the Vietnam of Computer Science links. Gave me a lot of details of the O-R problem, which of course, I don't agree is a problem at all.
Coming to the present: I suspect that a lot of Java application teams that are using Hibernate wouldn't have made the Hibernate choice after having a good DDD. Sometimes they may not be even aware of DDD. But if we ask them, they would say Yes, to : Do you have a set of domain classes? Do you have entities and value objects? Do you have aggregations? Do you have services? Do you follow design patterns like Factory?
But then, if we ask: Are you using DDD? Answer: Not sure. Have you read Eric Evans book? Ans: No.
So, I think such projects suffer from not having a proper DDD, and get along with having an accidental and partial DDD. Many teams go with Hibernate because their applications become portable across databases without much effort. This gives the marketing guys some talking points.
Thanks, Aleksey. And also for the Vietnam of Computer Science links. Gave me a lot of details of the O-R problem, which of course, I don't agree is a problem at all.
Coming to the present: I suspect that a lot of Java application teams that are using Hibernate wouldn't have made the Hibernate choice after having a good DDD. Sometimes they may not be even aware of DDD. But if we ask them, they would say Yes, to : Do you have a set of domain classes? Do you have entities and value objects? Do you have aggregations? Do you have services? Do you follow design patterns like Factory?
But then, if we ask: Are you using DDD? Answer: Not sure. Have you read Eric Evans book? Ans: No.
So, I think such projects suffer from not having a proper DDD, and get along with having an accidental and partial DDD. Many teams go with Hibernate because their applications become portable across databases without much effort. This gives the marketing guys some talking points.
Thanks, Aleksey. And also for the Vietnam of Computer Science links. Gave me a lot of details of the O-R problem, which of course, I don't agree is a problem at all.
Coming to the present: I suspect that a lot of Java application teams that are using Hibernate wouldn't have made the Hibernate choice after having a good DDD. Sometimes they may not be even aware of DDD. But if we ask them, they would say Yes, to : Do you have a set of domain classes? Do you have entities and value objects? Do you have aggregations? Do you have services? Do you follow design patterns like Factory?
But then, if we ask: Are you using DDD? Answer: Not sure. Have you read Eric Evans book? Ans: No.
So, I think such projects suffer from not having a proper DDD, and get along with having an accidental and partial DDD. Many teams go with Hibernate because their applications become portable across databases without much effort. This gives the marketing guys some talking points.
If you are referring to O-R impedance, my opinion is that it is not a problem or a problem that need not be solved through an ORM.
Developers are not going to stop using Hibernate or will not get rid of Hibernate in existing applications. My thought was that the number of database access frameworks other than Hibernate/JPA will increase. That's what I meant when I wrote 'the development world will move away from Hibernate/JPA.' The sentence perhaps didn't come out the way I was thinking.
If you are referring to O-R impedance, my opinion is that it is not a problem or a problem that need not be solved through an ORM.
Developers are not going to stop using Hibernate or will not get rid of Hibernate in existing applications. My thought was that the number of database access frameworks other than Hibernate/JPA will increase. That's what I meant when I wrote 'the development world will move away from Hibernate/JPA.' The sentence perhaps didn't come out the way I was thinking.
If you are referring to O-R impedance, my opinion is that it is not a problem or a problem that need not be solved through an ORM.
Developers are not going to stop using Hibernate or will not get rid of Hibernate in existing applications. My thought was that the number of database access frameworks other than Hibernate/JPA will increase. That's what I meant when I wrote 'the development world will move away from Hibernate/JPA.' The sentence perhaps didn't come out the way I was thinking.
Thanks, Lukas for clarifying. Maybe it's just my experience but the relational choice seems to be coming naturally for development teams. If you can keep the learning curve small as the framework evolves, it will be good for adoption. All said and done, there are two (main) concepts on the database side : primary - foreign key relationship and join tables. JDBC has only about six or seven steps to code. We shouldn't be needing a 900 page book to learn a new framework.
Thanks, Lukas for clarifying. Maybe it's just my experience but the relational choice seems to be coming naturally for development teams. If you can keep the learning curve small as the framework evolves, it will be good for adoption. All said and done, there are two (main) concepts on the database side : primary - foreign key relationship and join tables. JDBC has only about six or seven steps to code. We shouldn't be needing a 900 page book to learn a new framework.
Thanks, Lukas for clarifying. Maybe it's just my experience but the relational choice seems to be coming naturally for development teams. If you can keep the learning curve small as the framework evolves, it will be good for adoption. All said and done, there are two (main) concepts on the database side : primary - foreign key relationship and join tables. JDBC has only about six or seven steps to code. We shouldn't be needing a 900 page book to learn a new framework.
What I have seen is that once Java is chosen to develop applications, and the organization has quite a few Java developers, it becomes a Java shop. The language is already chosen. I just wanted to convey was that you can't be anything but object-oriented because of the language.
I think I could have worded the leading paragraph better.
What I have seen is that once Java is chosen to develop applications, and the organization has quite a few Java developers, it becomes a Java shop. The language is already chosen. I just wanted to convey was that you can't be anything but object-oriented because of the language.
I think I could have worded the leading paragraph better.
Comments
Feb 26, 2024 · Scott Sosna
Bravo ! How non-techies occupy senior technical / management positions and create havoc... very frustrating.
Sep 29, 2014 · Tony Thomas
Thanks, Aleksey. And also for the Vietnam of Computer Science links. Gave me a lot of details of the O-R problem, which of course, I don't agree is a problem at all.
Coming to the present: I suspect that a lot of Java application teams that are using Hibernate wouldn't have made the Hibernate choice after having a good DDD. Sometimes they may not be even aware of DDD. But if we ask them, they would say Yes, to : Do you have a set of domain classes? Do you have entities and value objects? Do you have aggregations? Do you have services? Do you follow design patterns like Factory?
But then, if we ask: Are you using DDD? Answer: Not sure. Have you read Eric Evans book? Ans: No.
So, I think such projects suffer from not having a proper DDD, and get along with having an accidental and partial DDD. Many teams go with Hibernate because their applications become portable across databases without much effort. This gives the marketing guys some talking points.
Sep 29, 2014 · Tony Thomas
Thanks, Aleksey. And also for the Vietnam of Computer Science links. Gave me a lot of details of the O-R problem, which of course, I don't agree is a problem at all.
Coming to the present: I suspect that a lot of Java application teams that are using Hibernate wouldn't have made the Hibernate choice after having a good DDD. Sometimes they may not be even aware of DDD. But if we ask them, they would say Yes, to : Do you have a set of domain classes? Do you have entities and value objects? Do you have aggregations? Do you have services? Do you follow design patterns like Factory?
But then, if we ask: Are you using DDD? Answer: Not sure. Have you read Eric Evans book? Ans: No.
So, I think such projects suffer from not having a proper DDD, and get along with having an accidental and partial DDD. Many teams go with Hibernate because their applications become portable across databases without much effort. This gives the marketing guys some talking points.
Sep 29, 2014 · Tony Thomas
Thanks, Aleksey. And also for the Vietnam of Computer Science links. Gave me a lot of details of the O-R problem, which of course, I don't agree is a problem at all.
Coming to the present: I suspect that a lot of Java application teams that are using Hibernate wouldn't have made the Hibernate choice after having a good DDD. Sometimes they may not be even aware of DDD. But if we ask them, they would say Yes, to : Do you have a set of domain classes? Do you have entities and value objects? Do you have aggregations? Do you have services? Do you follow design patterns like Factory?
But then, if we ask: Are you using DDD? Answer: Not sure. Have you read Eric Evans book? Ans: No.
So, I think such projects suffer from not having a proper DDD, and get along with having an accidental and partial DDD. Many teams go with Hibernate because their applications become portable across databases without much effort. This gives the marketing guys some talking points.
Sep 01, 2014 · Tony Thomas
If you are referring to O-R impedance, my opinion is that it is not a problem or a problem that need not be solved through an ORM.
Developers are not going to stop using Hibernate or will not get rid of Hibernate in existing applications. My thought was that the number of database access frameworks other than Hibernate/JPA will increase. That's what I meant when I wrote 'the development world will move away from Hibernate/JPA.' The sentence perhaps didn't come out the way I was thinking.
Sep 01, 2014 · Tony Thomas
If you are referring to O-R impedance, my opinion is that it is not a problem or a problem that need not be solved through an ORM.
Developers are not going to stop using Hibernate or will not get rid of Hibernate in existing applications. My thought was that the number of database access frameworks other than Hibernate/JPA will increase. That's what I meant when I wrote 'the development world will move away from Hibernate/JPA.' The sentence perhaps didn't come out the way I was thinking.
Sep 01, 2014 · Tony Thomas
If you are referring to O-R impedance, my opinion is that it is not a problem or a problem that need not be solved through an ORM.
Developers are not going to stop using Hibernate or will not get rid of Hibernate in existing applications. My thought was that the number of database access frameworks other than Hibernate/JPA will increase. That's what I meant when I wrote 'the development world will move away from Hibernate/JPA.' The sentence perhaps didn't come out the way I was thinking.
Aug 29, 2014 · Tony Thomas
Thanks, Lukas for clarifying. Maybe it's just my experience but the relational choice seems to be coming naturally for development teams. If you can keep the learning curve small as the framework evolves, it will be good for adoption. All said and done, there are two (main) concepts on the database side : primary - foreign key relationship and join tables. JDBC has only about six or seven steps to code. We shouldn't be needing a 900 page book to learn a new framework.
Aug 29, 2014 · Tony Thomas
Thanks, Lukas for clarifying. Maybe it's just my experience but the relational choice seems to be coming naturally for development teams. If you can keep the learning curve small as the framework evolves, it will be good for adoption. All said and done, there are two (main) concepts on the database side : primary - foreign key relationship and join tables. JDBC has only about six or seven steps to code. We shouldn't be needing a 900 page book to learn a new framework.
Aug 29, 2014 · Tony Thomas
Thanks, Lukas for clarifying. Maybe it's just my experience but the relational choice seems to be coming naturally for development teams. If you can keep the learning curve small as the framework evolves, it will be good for adoption. All said and done, there are two (main) concepts on the database side : primary - foreign key relationship and join tables. JDBC has only about six or seven steps to code. We shouldn't be needing a 900 page book to learn a new framework.
Aug 27, 2014 · Tony Thomas
What I have seen is that once Java is chosen to develop applications, and the organization has quite a few Java developers, it becomes a Java shop. The language is already chosen. I just wanted to convey was that you can't be anything but object-oriented because of the language.
I think I could have worded the leading paragraph better.
Aug 27, 2014 · Tony Thomas
What I have seen is that once Java is chosen to develop applications, and the organization has quite a few Java developers, it becomes a Java shop. The language is already chosen. I just wanted to convey was that you can't be anything but object-oriented because of the language.
I think I could have worded the leading paragraph better.