Win a copy of Java 9 Revealed this week in the Features new in Java 9 forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Is this package structure correct?  RSS feed

 
Monica Shiralkar
Ranch Hand
Posts: 911
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have an application which has usage of both oracle database(relational db) as well as hbase (nosql database).Is the below package structure correct:


com.mydomain.myapplication.analytics.sql.dao.impl.oracle

com.mydomain.myapplication.analytics.nosql.dao.impl.hbase

thanks


 
Dave Tolls
Ranch Hand
Posts: 2554
27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does your application really care where the data comes from?
I would forget about the sql/nosql split entirely.

...analytics.dao

would be where my dao interfaces would sit, with the impl.oracle and impl.hbase underneath.
 
Stephan van Hulst
Saloon Keeper
Posts: 7190
118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not even sure if the impl part is necessary. The oracle and hbase parts already kinda imply that they're implementations.
 
Dave Tolls
Ranch Hand
Posts: 2554
27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good point!
One less layer...
 
Monica Shiralkar
Ranch Hand
Posts: 911
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks all.

I did the correction. I still have below doubts:




Should the package structure be like the below now?




Also, what should be the location of DAOFactory.java which has methods getOracleDAO and getHbaseDAO returning the instances of OracleDAO and HbaseDAO ?
 
Dave Tolls
Ranch Hand
Posts: 2554
27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The interface would be in the dao package, along with the factory.
As I say, the rest of your code shouldn't care which particular version of the DAO is being used.  At least in most cases.

So:
com.mydomain.myapplication.analytics.dao contains the Dao.java and the DaoFactory.java
com.mydomain.myapplication.analytics.dao.oracle contains the OracleDao.java
com.mydomain.myapplication.analytics.dao.hbase contains the HbaseDao.java
 
Monica Shiralkar
Ranch Hand
Posts: 911
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks. Actually the below two are different interfaces:



Let me call them AbcDAO and XyzDAO to avoid confusion.

So still the structure should be as suggested above? 


So is the below correct?

 
Stephan van Hulst
Saloon Keeper
Posts: 7190
118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That makes no sense to me. Why are the two interfaces different? And if they are different, why do you need interfaces? Are you expecting multiple implementations per interface?
 
Monica Shiralkar
Ranch Hand
Posts: 911
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The interface ABCDao.java (implemented by OracleDao.java) would be having methods such as  readConfig, fetchUserInfo which are required to be fetched from the relational database whereas interface XYZDao.java (implemented by HbaseDao.java) would be having methods such as read, write which would be to read and write database to nosql database during big data analytics.
 
Stephan van Hulst
Saloon Keeper
Posts: 7190
118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Those are implementation details. Why doesn't XYZDao contain readConfig and fetchUserInfo methods, or alternatively, why doesn't ABCDao contain read and write methods?
 
Dave Tolls
Ranch Hand
Posts: 2554
27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd still have the interfaces together, and the implementations in whichever DB package makes sense.

Unless there's something special about one of the data sources.

This is likely to be one of those instances where we would have to know a lot more about the system to make a more solid answer.
 
Monica Shiralkar
Ranch Hand
Posts: 911
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst
Those are implementation details. Why doesn't XYZDao contain readConfig and fetchUserInfo methods, or alternatively, why doesn't ABCDao contain read and write methods?


Actually, instead of having a big common DAO, I thought of keeping it into two two different DAOs so that it is more organised too with one DAO being for functionalities such as fetching configuration and user information from relational database and the other DAO being for a different functionality such as saving huge amount of raw data into nosql database. Will keeping two different DAOs not keep it more organised and shorter classes?
thanks
 
Stephan van Hulst
Saloon Keeper
Posts: 7190
118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can you explain a little bit what the "huge amount of raw data" is supposed to be?

Personally I'm a big fan of the Repository pattern. For instance, for your user info I would have an interface com.mydomain.myapplication.analytics.data.UserRepository, and a class com.mydomain.myapplication.analytics.data.jdbc.JdbcUserRepository. The interface is not in an implementation specific package, because we might implement a repository of users using a nosql database as well as a relational database.
 
Campbell Ritchie
Sheriff
Posts: 54033
130
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since this is the Beginning forum, please explain a bit more about the repository pattern, Stephan.
 
Stephan van Hulst
Saloon Keeper
Posts: 7190
118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, basically you create classes that are each responsible for storing and retrieving one particular type of object, or information about that one particular type of object. How it's done or what backing storage is used is an implementation detail.

For instance, UserRepository could look something like this:
 
Monica Shiralkar
Ranch Hand
Posts: 911
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can you explain a little bit what the "huge amount of raw data" is supposed to be?


thanks. To answer your question , the data will be continuous stream of data from the sensors.This will be stored in hbase database.
 
Monica Shiralkar
Ranch Hand
Posts: 911
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For instance, UserRepository could look something like this:


ok.Along with UserRepository methods, suppose there is a second kind of functionality which is unrelated to User, then in that case should I use different DAOs?
 
Stephan van Hulst
Saloon Keeper
Posts: 7190
118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, I don't think that you're going to read a huge amount of data from your database in one go, right? You'll probably want to filter out specific pieces of information that you're interested in, so you should model those specific pieces of information, and then create another repository interface for a specific type of information.

Let's for a moment assume that you have a big database full of temperature readings over many years. Let's also assume that one of the things that you're interested in is getting all readings between two specified times. Here's what the interface could partially look like:

Just add more methods if you need different ways to filter the data.

You can then have a HBaseTemperatureReadingRepository implementation class that transforms these method calls to highly performant searching and filtering operations on your HBase driver.

As you can see, you don't need one DAO per database driver, but instead you can separate your code into one repository per data type.
 
Monica Shiralkar
Ranch Hand
Posts: 911
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am trying to understand that for what reason would someone have different classes implementing an interface using different databases.
 
Stephan van Hulst
Saloon Keeper
Posts: 7190
118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Requirements change. It happens. When they do, you don't want to be stuck with tightly coupled classes that force you to rewrite your entire application. What if at one point you want to take your user info out of a NoSQL database as well? With the repository pattern, it's as easy as swapping out one implementation for another. It also allows you to mock your databases for testing purposes.
 
Monica Shiralkar
Ranch Hand
Posts: 911
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

There is an issue with below design that OracleDAOFactory does not need the methods of SensorDataDAO such as saveSensorData (it needs only methods such as readConfigInfo,fetchUserInfo . Similarly HbaseDAOFactory does not need methods such of UserDAO such as readConfigInfo,fetchUserInfo (it needs only methods cush as saveSensorData ). In the the below design both will need to have all the abstract methods implemented (although only half are needed).   Thus the methods needed for hbase are unrelated to the methods for oracle.



What can be a solution to the above issue?
 
Dave Tolls
Ranch Hand
Posts: 2554
27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is where I would use something like Spring to wire up the specific implementations, and not use a factory.

Your HBase and Oracle databases do different things, so it doesn't look like there's any overlap between DAOs (or Repositories), so in a running application a particular DAO will only ever have either an Oracle implementation or an HBase one.
 
Monica Shiralkar
Ranch Hand
Posts: 911
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have created two separate factories as below for different type of operations : User operations involving oracle (or later mysql)  and Sensor operations involving hbase (or later cassandra). I have kept these in different packages as below:





and the below in another package:



Is this design fine now?
 
Campbell Ritchie
Sheriff
Posts: 54033
130
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't know.
I presume you know what the compiler errors are in your last bit of code. There is something wrong with using ints in a switch statement if you can use enum elements instead. Indeed, using the enum may make the switch unnecessary. I am not convinced it is a good idea to return null from that method. And why do the methods in the two classes look so similar? Since they both have the same misprint, have you used copy‑and‑paste?
Put your .java classes in folders whose names correspond to the package structure. You can either have the .java and .class files in the same locations or you can use a src folder and a bin folder to separate the two. It depends on what you are going to distribute as the .jar file.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!