Creating a motivation for developers to make unit testing part of the software development process can be challenging. Although tests can be made a requirement, without clear understanding of the practical purpose of testing, developers might write tests only to pass the code review and keep the code coverage metrics high. However, if the project manager does not force the developers to write tests, who will? I believe that it is the project itself.
DAO (Data Access Object) is an abstraction that is used for CRUD database operations. In Java, DAO is typically implemented as an interface that declares the methods through which a programmer can interact with a database table. A DTO in the form of a POJO object is used by DAO as a data container, which passes data from a programmer to the database and vice-a-versa.
After analysing the criticism about DAO, I have decided to write out my personal thoughts on this subject. In this article I will create an implementation of DAO through the perspective of SQL-speaking objects.
The well-known disadvantages of getters have already been analyzed by a number of programmers. Yegor Bugayenko has gone even further and suggested a workaround. The pattern called Printer gives indirect access to the internal parts of an object by serializing it into one of the data formats, such XML or JSON and reading it’s content using an XML or a JSON reader. As a result, as Yegor states, the object stays intact and it’s encapsulation is not violated by getters. Although this approach might seem viable at first sight, I believe that it does not solve the fundamental problem of accessor methods.
Most people who start a blog face the questions that are common for newcomers: How to make it popular? What blogging platform to choose? And, in some cases, how make money from it? However, these questions have no exact answers, just as there are no magic bullets for blogging. The moment you realize that, you change your strategy and start looking for successful bloggers and try to learn from their experience. One of such bloggers is Yegor Bugayenko the author of the “256 Bloghacks”.
The disadvantages of Object-Relational Mapping (ORM) have already been discussed by a number of developers. The main argument against ORM is that it leads to the creation of DTOs, which encapsulate data, rather than behavior. If one decides to accept this claim, what alternative solutions does he have? One of them is a SQL-Speaking object.
In the comments section of one my recent articles I have been asked the following question: “Why do DTOs lead to temporal coupling?”. Seriously, why? Have we not been using them for years in Java without critically thinking about what could be wrong with them?
The concepts of information and data have drawn a lot of attention from the public in today’s age of big data and data mining. However, the application of these terms in OOP is yet to happen.
DTO (Data Transfer Object) has long been a source of discussions on the subject of it’s place in OOP. Most often, the debate occurs on the topic of practical difference between a DTO and an entity (an object which represents a real-world subject). Some programmers, who are against DTO as a concept, have been able to demonstrate through convincing arguments and examples why DTOs should be avoided. However, the question of practical alternatives and common mistakes in them still remains open.
