Data Persistence Layer

The last step of the compound registration workflow persists compound data into the database. This step is accomplished by a RegistrationService object along with a data persistence layer, which will be discussed in the next chapter. 

The Data Persistence Layer can be a thick layer that resides in the application middleware or a thin layer in the application middleware combined with some stored procedures in the database. The former makes the Data Persistence Layer independent of the underline RDBMS that is being used. The latter provides better performance because the number of network calls can be reduced. Either way, a wed-defined interface between the Business Layer and the Data Storage Layer is the key. 

There are a few design options for the Data Persistence Layer. Here we use the Data Mapper Pattern (Fowler, 2003b). The reason is that we want to separate the domain layer and the database schema and allow them to evolve independently. 

The Data Persistence Layer performs four types of operations in the database on behalf of the Business Layer query, insert, update, and delete. These operations are invoked by the service objects in the Business Layer. In Chapter 12, we presented one type of service—the Registration Service. There are other types of services such as Query Service and Update Service, each of which leverages the Data Persistence Layer to perform database operations. 

In the case of the chemistry database, the situation is more complex. Compound data cannot be queried or updated using standard SQL. The read and write operations are encapsulated in vendor-specific Oracle data cartridges. Therefore, the Data Persistence Layer has another responsibility— hide vendor specifics with a standard interface so that the Business Layer does not care about vendor variations. 

The first interface of the Data Persistence Layer is the finder interface— the interface for querying the database. Two types of queries must be supported by a chemical information database one is numeric or text query, and the other is structure query. The first type is the same as any other type of database. The second type is where chemistry databases differ—search the database based on substructure, structure similarity, and structure flexmatch. As such, the finder interface has to support these two types of finder methods. The CompoundFinder interface is as follows ... 

---