I've been following a book that is essentially a tutorial on designing web services, and have been applying it to a specific problem that I need to solve. My question(s) isn't specifically about web services I suppose, just design in general.
The simplified problem is this: I need to expose a product inventory from our ERP system. I'll need two views of this data - one which will be a full inventory list for internal use, and another which will be a subset of inventory items appropriate for public consumption. Ultimately I'm exposing everything via web services.
I've got the technical details out of the way. That is, I've got the data, have some test cases, and even have a little Liferay portlet that shows the public inventory. I'm having a hard time with the design itself though, especially considering that I know this project will increase in magnitude.
So the book had me create a model consisting of classes that are essentially data structures representing my business objects. So I've got InventoryItem, InventoryItemPriceSchedule, and stuff like that. I populate these things via a data access object, so I've got an InventoryDAO interface and an InventoryJdbcDAOImpl concrete class that uses JDBC to pull from my data source.
Now the part(s) where I'm getting confused. The book had me create a "service" package in my project...the word "service" seems to have many meanings... the service interface defines a facade that essentially delegates requests to the DAO interface. The book is calling it a facade here, and I'm not sure if it is. Basically the code looks something like this:
Ok... so I understand how this thing isolates the data layer, but is it a facade if it's just delegating requests to the data layer? The problem with books and tutorials is that they're over simplified. What should this service object...thing... be doing? Should it map requests to the DAO on a one-to-one basis? That seems a little bit silly since I could just not call the InventoryDAO a DAO and just use its interface and skip this layer of abstraction.
I think that the reason the book chose this method might be that there can be multiple implementations of the service... so I might have a facade that uses my Jdbc DAO, and another that uses some other type of data access. (in other words, I have an implementation class that creates the InventoryFacade concrete class and gives it a reference to my DAO concrete class, and returns a new InventoryFacade interface) But I can't imagine why that would ever be necessary in this case.
Finally the book had me create a whole new project which I believe represents my "web service". It calls my InventoryFacade to populate data transfer objects. I generate my web clients from classes in this project.
So here comes the matter of my public vs. internal inventory. In my actual DAO object my method to retrieve items takes an optional list of item numbers to retrieve. Through this mechanism I can specify to only retrieve "public" item numbers, or retrieve all item numbers. Good. But then where do I implement the logic to "only retrieve public items" or "retrieve all items"?
Do I create methods in my InventoryFacade like getEntireInventory() and getPublicInventory()? That would require logic there and I'm not sure if there should be any. Besides, what happens when I want to getSomeOtherSubsetOfInventory()?
So I'm thinking that this logic should go up in the web service itself. Yeah? Nah? What if my list of public inventory items is in the database itself...I would then have to add a method to my facade to getPublicItemNumbers()...which then causes the same problem I mention in my last paragraph: what happens when I want to getSomeOtherItemNumbers()?
And in regards to the web service, the DTOs I'm creating apply to both my public and private web services. How / where do I share them?
I don't think I'm making much sense. I'm holed up in details here even though I've got the functionality working. I just want to figure out how to do this right. I've been away from development for far too long.
Please, any advice would be much appreciated.