Where do import / export / remote services fit into an MVC web project?

[Bo Larson]

Please be nice, I'm all alone out here and am new to many of these concepts.

I'm writing a spring MVC 2.5 application and I've got the thing organized into what I believe is a fairly standard structure. I've got DAOs over here, domain pojos over there, a service layer, and then my controllers and presentation.

Everything is working fine, but I've got these classes and I don't know where they fit....like...where do I put them? What do I call them? What "kind" of classes are they in terms of all this design pattern madness (DAOs? Services? Wha?).

1) I've got an interface that I'm currently calling CustomerImportService. Its implementation queries a local ERP database and returns Customer objects (part of my domain model) which my application can then save in its own database.

2) I've got an interface called CustomerExportService. The implementation of this thingy exports Customer objects to a remote database.

3) I've got an interface called ContactPortalService. Its implementation takes a Contact from my application and adds / updates / deletes an associated user account on an external portal server via SOAP.

All three of these classes use services of one form or another that are external to my actual application. I don't know exactly where they fit though in my project structure. They're not part of the DAO layer I wouldn't think, although the import and export classes are sorta like DAOs. They could be considered services, but they are services local to my application, not services in the sense that some higher up client will be using them. Where do they fit into my application / project structure?

(thankfully this thing is working ok...I just want to realize my application in the context of standard practices)

[Jimmy Clark]

Based on your description, these three objects are data access objects and are logically part of what you are calling a "DAO layer."

In terms of the Java EE three-tier programming model, there are part of the Business tier.

Keep in mind that there are many different ways to implement the Data Access Object design pattern.

For example, the CustomerImportService object is accessing customer data somewhere in the system.

I would rename these interfaces and remove the term "Service" from them. There are not implementations of a "web service" and are simply data access objects. CustomerERPDAOImpl might be more appropriate.

[Bo Larson]

Thanks!

I guess the reason I didn't consider them "DAOs" is they perform such specific tasks that aren't really related to persisting data for my application. The CustomerImportThing only supports looking up a customer in the ERP system. It doesn't access any data local to my application, it just has methods like public Customer getCustomerByCustomerNumber(String customerNumber), which returns a Customer object populated with data from the ERP system...from there I can persist this object using my CustomerDAO. Likewise, the CustomerExportThingy only has operations for saving and deleting Customers from an external database.

Then the PortalService is what really threw me....but I guess I can sorta think of it as a data source. Again, however, it doesn't actually persist any data for my application.

Let's say I had some other class that would publish a customer's photograph to Flickr...would it also be considered a "DAO"?

[Jimmy Clark]

The Data Access Object object-oriented design pattern is applied to "data access" requirements. This certainly includes more activities than "persisting data." Moreover, it can be applied to any data, not just internal data in your code.

Data Access Objects encapsulate data access operations, whether data is from an external source or an internal source. The design pattern applies to accessing data period. There are no constraints within the pattern or how it is implemented.

A DAO can encapsulate execution of a stored procedure within an external database or an internal database.

The purpose of the pattern is to separate "data access" operations and "business logic" operations, and allow them to communicate when needed. Business objects should not be exposed to the low-level details of data access and business logic code should not be "polluted" with data access code. This separation is very good for many reasons. Read up for the Data Access Object design pattern for more details.

Good luck!