C# Design Patterns – Using the Request Manager Pattern

cdesign-patterns

I have observed in lot many C# example where in following pattern is being followed but i am not sure how this will going to help us in long run

Typical approach i have seen is

create a interface
implement interface
create a manager
call manager

it would be really nice if anyone can tell me how this approach will going to help in real world senario

interface IRestService for various web requests

public interface IRestService
    {
        Task<List<TodoItem>> RefreshDataAsync ();

        Task SaveTodoItemAsync (TodoItem item, bool isNewItem);

        Task DeleteTodoItemAsync (string id);
    }

Code that implements IRestService interface

public class RestService : IRestService
{
    HttpClient client;

    public List<TodoItem> Items { get; private set; }

    public RestService ()
    {
        var authData = string.Format("{0}:{1}", Constants.Username, Constants.Password);
        var authHeaderValue = Convert.ToBase64String(Encoding.UTF8.GetBytes(authData));

        client = new HttpClient ();
        client.MaxResponseContentBufferSize = 256000;
        client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", authHeaderValue);
    }

    public async Task<List<TodoItem>> RefreshDataAsync ()
    {


    }

    public async Task SaveTodoItemAsync (TodoItem item, bool isNewItem = false)
    {

    }

    public async Task DeleteTodoItemAsync (string id)
    {

    }
}

Manager that calls the implemented methods

public class TodoItemManager
{
    IRestService restService;

    public TodoItemManager (IRestService service)
    {
        restService = service;
    }

    public Task<List<TodoItem>> GetTasksAsync ()
    {
        return restService.RefreshDataAsync (); 
    }

    public Task SaveTaskAsync (TodoItem item, bool isNewItem = false)
    {
        return restService.SaveTodoItemAsync (item, isNewItem);
    }

    public Task DeleteTaskAsync (TodoItem item)
    {
        return restService.DeleteTodoItemAsync (item.ID);
    }
}

to execute request

TodoManager = new TodoItemManager (new RestService ()); 
TodoManager.GetTasksAsync ();

few questions are running in my mind

why we need a manager why can not we just use RestService
if some day i need to develop one module to fetch contact related data from server then do i need to add methods in IRestServie to addContact() , deleteContact() , getContact()

Best Answer

Why we need a manager?

The manager represents the business logic that surrounds calling a rest service. Your example was a little to simple to see why a manager can be useful. Consider the use case where you need to deal with multiple REST services. But this is where you can handle pre-validation of data, do a follow-on call if addContact succeeds or fails, etc.

Why not use `RestService` Directly?

Testing. It makes testing your business logic (manager) separately from your rest service.

Versioning. It makes replacing the implementation of your RestService easier when the implementation needs to change due to versioning constraints.

Containment. The primary reason is to contain your business logic separately from your presentation logic. It also minimizes the impact if the new version of a RestService causes some extra steps that you have to maintain in code. By keeping one interface you have control over the same (your manager) you can contain the changes required by a change in an interface you don't really have control over (rest service).

Fetching new data from a new service

IRestService is a bad name for this reason. You would have separate interfaces for each REST service you needed to contact. For example, you would have a ITodoRestService and a IContactRestService or something like that. If your TodoManager needed to use both (i.e. associating todo items with a contact), it would have a reference to both. Which then leads you back to why we need a manager in the first place.

Related Solutions

Java – A design decision in composition or aggregation

There's a lot to say here.

Inventory's api looks like a value object (since it has no identity, on its own, I suppose that it belongs to a Player). If so, it should be immutable, returning a new instance each time you add or remove an Item.
Your Item class looks like a shared identifier, thus it should override equals and hashcode and (strictly speaking, in DDD term) it should not hold any reference to the icon since it's not useful for its own invariants. You should use a domain service that take the Item and provide the proper icon instead (probably wrapping a statically defined Hashtable). However, be pragmatic with this: if you measure actual performance issues with such (formally correct) approach, keep the field there.
The Slot, as it stands, cannot be considered a domain object, because it does not implement equality in a domain relevant way (it ignores the quantity). This is perfecly correct for a private class internally used by the Inventory, but should not be exposed to clients (as in the second Inventory's implementation of the first solution you proposed). This because the clients could compare for equality two Slots from two different players, obtaining unreliable results.
To get rid of most boilerplate code, I would code
- a supporting functor interface like ItemQuantityChanger (below)
- a "functional" immutable collection, say ItemsSet, with a metod of signature ItemsSet set(Item item, ItemQuantityChanger transformation) that iterates over a simple array for the item to change. Such method would always create a new ItemsSet to return, without the Item (if the trasformation returns zero), with a new Item if the item is not found (with the quantity returned by applying the transformation to zero) or simply with the previous item coupled with the result of the trasformation.

However, concretely, I would just use an ImmutableList.Builder, since the functional design described in 4 adds few value in this case. A single if, in a method, is not that huge smell.

public interface ItemQuantityChanger {
   /**
    * Accept the current quantity of an Item and return the new one.
    */
   int applyTo(int currentQuantity);
}

C# Validation – Best Way of Validating Class Properties

If I needed to input data and capture errors, I would probably do something more like:

public class Employee
{
    public int EmpID { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Salary { get; set; }
}

public class ErrorEmployee : Employee
{
    public string[] ErrorReason { get; set; }
}

Read CSV file row by row
For each element i.e EmpId, FirstName... etc do the required validations by calling individual methods having validation logic. eg: public bool ValidateIsDecimal(string value) { } public bool ValidateIsEmpIdExists(string value) { } etc
If valid, fill corresponding property of "Employees" class. Add this Class to Employees collection (eg: List)
If NOT VALID, fill "ErrorReason" property, with appropriate reason as to what caused the validation to fail.(eg: Required filed was missing or datatype is not decimal etc) Add this Class to ErrorEmployees collection (eg: List)

I wouldn't want to pollute the regular Employee (singular, use the plural for a collection of them) object with error messages. As in the note above, check out the FluentValidation library for your validation and capture a list of errors rather than just the first found.