Construction of the BO in Java EE

[PARRISH]

We will then create our BO, following similar steps to build the DAO. Obviously, we must invoke the DAO BO to solve the data access. The most important obstacle to overcome at this stage will invoke the Dao. For now, build it directly with the familiar "new." We will be something like:

• ProvinciaDao ProvinciaDaoImpl provinciaDao = new ();

Do not worry if BO code seems to be just a "we" in this class stands the business logic, and for this simple interface does not take any further action. Remember to create the corresponding test with the different test cases.

Once completed, we then BO and DAO functional. The DAO is a dummy, but service business is perfectly functional for use. That is, a team of a top layer could continue to work with this implementation until the real and final implementation is available. However, let's review the recent implementation of our BO: it has an interesting problem. Let's review again how we are getting our Dao instance:

• ProvinciaDao ProvinciaDaoImpl provinciaDao = new ();

This line represents a serious problem for our BO. In a layered architecture, we assume that such a claim unknown layer layer implementation service provider (so as to be independent of implementation). But here, our BO knows explicitly the implementation of the Provincial Dao ... in fact, is doing a "new" in this implementation!

Further, we have another problem, this time in our test unit. Remember, we said that a unit test "isolate" the kinds of dependencies. However, the test of our BO depends on the operation of the DAO: DAO implementation if fail, we fail BO too. In fact, without the implementation of the DAO is not possible to test our BO. In summary, we have two major problems:

1. The BO test is not unitary.
2. Bo knows the implementation of DAO. You can not easily change the implementation in the BO.

[PARRISH]

Obviously, we avoid making a "new ProvinciaDaoDummyImpl ()" or, for that matter, a "new" in any DAO is used. As we saw, perform a "new" we coupled with a particular implementation of a DAO. Since the problem is to make the "new", it is clear that we must not further instantiate BO himself to the DAO. That is, delegate instantiation of this DAO to another party.

Here we apply a pattern that will be fundamental in the design of our JEE applications: it is Dependency Injection (Dependency Inyection - DI). This pattern states that an object is not responsible for check its dependencies, but these must be checked by a third party. Thus, what we do in the implementation of the BO will be:

• locate the DAO as a private attribute of our BO (in the Class Diagram)
• create you the getters / setters for (in the Class Diagram)
• private attribute directly used in our method (on the Sequence Diagram)
• update the code to reflect these changes

However, when running the tests, they fail for a nice NullPointerException surely ... and that is, who has checked our DAO? Then our test will be who need to create an instance of the DAO, checking BO, and only then run the test. To bring the test then!

[PARRISH]

With this, we solved the problem in our BO: now I do not know the implementation of DAO. In fact, it has no way to obtain it, only expected to be correctly. Obviously, this will generate another question: If BO Sets its dependencies not, then who the actual implementation? Obviously someone must be responsible for knowing the implementations and dependencies checking an objects. This issue will solve it later, but for now just know that objects "have some units," no matter how. There remains however a problem to solve: our test unit still not. The same test is creating the damage and setting it to BO. Obviously, BO is not independent of their environment.