Database Layer Design

Question

I have a question about the level of design in one of my projects. I am working on a project in which I need to get some objects using REST. Say, for example, customer samples and their display in the list.

The following operations that can be performed on the client are:

• Add customer
• Editing customer information
• Delete customer

So I was thinking of including a class called "CustomerManager" that includes the following methods:

@interface CustomerManager - (CustomerManager *)sharedManager; - (BOOL)addCustomer:(Customer *)customer; - (BOOL)deleteCustomer:(Customer *)customer; - (BOOL)updateCustomer:(Customer *)customer; @end @implementation CustomerManager - (BOOL)addCustomer:(Customer *)customer; { NetworkManager * manager = [NetworkManager manager] addCustomer:customer ]; } @end 

In the ViewController, where ever I need to perform operations related to the client, I did it like this,

  Customer * manager = [Customer sharedManager]; [manager addCustomer:customer]; //fetch customer [manager customers]; //While deleting [manager deleteCustomer:customer]; 

Everything looks and works fine until I get a question at the design level why there was a manager between them. All the work was done on the Customer object, so you need to have all the operations related to the Client in the client class, for example, something below.

  @interface Customer + (BOOL)addCustomer:(Customer *)customer; + (BOOL)deleteCustomer:(Customer *)customer; + (BOOL)updateCustomer:(Customer *)customer; + (NSArray *)customers; @end 

The problem is that although the network code is in a separate class, I need to have a specific link from my network manager in all my model classes. Confused which one to choose.

What was the best way ?. I would like a detailed answer for this.

Answer 1

I do not believe that there will be a correct answer. I personally went back and forth about how my web services interact with my models. But I can provide you with a few pointers:

• CustomerManager is full. The Customer model is responsible for managing yourself - you can place methods related to the Customer within it. Here you do not need a separate object.
• I usually use a superclass for my models. So, for example, you might have a class called ApplicationModel that the Client and all your other models inherit from. This is a great way to DBMS code in your models. If you decide to use network code in your models, I would suggest placing it in this superclass. Thus, if you need to make changes to the work of web services, you only need to change the code to 1 place.
• In general, I would suggest keeping the network-related code separate from your models. I like it when my network logic is as isolated as possible. The code associated with the network is subject to change, and you want to minimize the number of places in which changes in the network affect your code. For example, I usually create a class that acts as an API wrapper and provides a public interface for making API calls. This class is also responsible for analyzing the responses of these methods and interacting with models (i.e., analyzing a custom JSON array and interacting with the Client to add these objects to the database).

Answer 2

I disagree with Michael Frederick at his first point.

Your CustomerManager is a much better idea than doing CRUD client operations with the Customer model object itself. The first and main reason is that the single client of the class model of the client must be represented by an individual client; in addition, to manage the recruitment of customers (the principle of shared responsibility). In terms of DDD, I would expect the Customer class to be an entity .

Note that there is a big difference between the model object (as in the MVC template) and the domain object. The main difference is that the responsibility for the object-object is to provide a presentation with the presentation of some data, and the responsibility for the object-domain is and should not be a logical translation of the concept of a domain, regardless of the presentation.

As I can tell, from your controller your model should contain a set of clients. Therefore, I have a CustomerModel for storing Customer objects. The responsibility of the dispatcher is to process requests and manage the model accordingly based on the request so that the result is a consistent view of the application state. This should not and should not be responsible for CRUD operations. Typically, in a tiered project , an application-level service will be responsible for operations that are likely to delegate it to the infrastructure level of the repository (or DAO). Combining it, at least, my design will look something like this:

All CRUD, request passing, and state management are performed on the left side of this UML diagram.

Another way to take a look is that in the simplest of terms, all this can be several lines of code. Let them say that you are doing the same CRUD operation in an array. Should array elements be responsible for managing the array? Of course not. CustomerRepository is an array, NetworkManager is its persistence (i.e. Memory), a controller is an actor that uses an array, CustomerModel is a local copy or subset, and Customer is an array element.