Java – the best design to decompose business logic and data layers when they appear to overlap?

I'm building an MVC web application (using the spring MVC framework), and I'm a little confused about the best way to design a specific region

An application must interact with a series of Web services, which are not really perfectly designed and do not provide many abstractions per se - basically, each create / update / retrieve / delete operation has a web service method There are not many APIs for each "data type" Web service clients need to know which methods to call and in what order they can create the required data - in other words, there is no "transaction" based method

For example, just create a new user account, you need to call a total of seven different web service methods to set all records in the necessary table (user record, add correct permissions for the user, set the user's bill details, etc.)

I'm trying to abstract it in the best way and encapsulate it in our application Most applications follow standard processes:

request ---> Controller <---> Service/Business-level object <---> DAOs for data access

In my application, I use my own set of "domain objects" to represent and abstract the data types defined in Web Service WSDL, so my domain logic does not depend on Web service types, so we can abstract and hide which details we like

I'm looking for some ideas that are the best way to design the "user creation process" mentioned above The process of creating "regular users" involves invoking seven different web services, as I mentioned, but this is only one "type" of users - we must be able to create several different types of users, and each user needs a different web service to be invoked

At present, I just designed this "regular user" creation as a proof of concept - I have a domain object user, a userdao interface, getuser (name) and CREATEUSER (user) methods, and a webserviceuserdao, which implements the userdao method and knows how to call the above seven web service methods The CREATEUSER () method is called by usercreationservice, which is my business / service level class, and the latter is called by signupcontroller

However, to extend this logic so that different user types can be created (represented by different values in user. Gettype()), I am not sure where to draw the line between the business / service layer class and Dao For example, I should:

>Create a userdao implementation for each "user type", so the logic for creating each "user type" can be encapsulated in its own class to let usercreationservice decide which userdao to use? This will correspond to one service class: many Daos. > Should I divide userdao into smaller parts, one corresponding to each "record" that needs to be created in the web service / database, even if my entire application does not need to know each of these individual types? Then provide different usercreationservice implementations for different "user types"? In other words, even if I don't need the corresponding privilege or billingplan domain object, this policy will have privileges Dao, billingplan Dao, etc This will be many service classes: many Daos. > Contains all the logic to invoke a web service for each "user type" in a single webserviceuserdao? This will have a very complex disadvantage class (and PMD is already complaining about circle complexity), but all these logic will be encapsulated in one class, which may reduce the complexity from the perspective of the overall API

One of my goals for this application is to ensure that if we have to change the details of data persistence, all we need to do is change the Dao implementation – if we have to start connecting to different billing systems, I don't want any part of the application to change outside the Dao level

Any comments? What strategy do you use when deciding when to decompose business logic and data access logic?

Solution

Maybe you can have three layers instead of two: "an additional indirect layer"

At the top level, you may have business logic that does not understand data access: this business layer uses classes such as user, account, and user Getaccounts and account Getowners and other factory methods

The underlying layer may be the data access layer, which is the wrapper or appearance of your data layer

Between these two layers, one layer knows what your business objects are (such as users and accounts), not your business logic The middle tier knows your data access tier The job of the middle layer is to use the API of the data access layer to I / o your business objects