C# - How to create an implementation contract with subclasses to be implemented?

Question

I would like to create an interface (called Interfacex)

interface InterfaceX
{
...
}

Where your future implementation returns the following structure:

ClasseDaInterfaceX.ClasseA.Metodo1daClasseA(parametro);
ClasseDaInterfaceX.ClasseA.Metodo2daClasseA(parametro);
ClasseDaInterfaceX.ClasseB.Metodo1daClasseB(parametro);
...

That is, the result would be a class with two nested classes. However, that the methods of the Classea and Classeb classes also need to be implemented.

Follow the concrete example:

Imagine a system you can use as a "database," anything. In a certain place I can use SQL Server. Some other Firebird place. In another I can use a webservice or even a text files!

The implementation of this DLL will depend on the conditions I will find in the place using the system.

So I need to create an interface with all the routines, their inputs and their returns, so that future Dlls can implement it, thus following the contract.

However, imagine that this system can have hundreds of methods of accessing the database.

Imagine an interface with 250 methods, for example. In my view, it’s bizarre.

So I thought: is there a way for me to organize this interface with "subclasses" or with "subinterfaces".

It would be something like the example below:

interface IDatabase
{

    interface ClienteDB
    {
        public bool Create(Cliente);
        public Cliente Read();
        public Cliente Update();
        public bool Delete();
    }

    interface FornecedorDB
    {
        public bool Create(Fornecedor);
        public Fornecedor Read();
        public Fornecedor Update();
        public bool Delete();
    }

    ...    
}

With this, it would have a well defined and relatively organized contract, which would force the implementation of the DLL following the same organization.

And access to methods would look like this:

Database.Clientes.Create(...);

Is there any way to create an interface like this in C#?

Answer 1

Good morning!

You can use a Design Pattern known with Rrepository, as it abstracts the storage of the model.

This Design Pattern aims to isolate the data persistence code from business rules so when it is necessary to change the database it will be simpler and only necessary to modify the repository.

Code example:

public interface Repository<T> {
    bool Create(T item);

    T update(T item);

    bool remove(T item);

   T Read(int id);
}


public class ClienteRepository : Repository<Cliente>
{
    public bool Create(Cliente item){
        //DB insert
    }
    public Cliente update(Cliente item) {
        //DB update
    }

    public Cliente update(Cliente item) {
        //DB delete
    }

    public Cliente update(Cliente item) {
        //DB delete
    }

    public Cliente Read(int id){
        //DB Select
    }
}


public class Cliente
{
    public int Id { get; set; }
    public string Nome { get; set; }
}  

Learn more about Design Pattern in the links below:

• https://medium.com/falafel-software/implement-step-by-step-generic-repository-pattern-in-c-3422b6da43fd
• https://martinfowler.com/eaaCatalog/repository.html
• http://www.macoratti.net/11/10/net_pr1.htm
• https://docs.microsoft.com/pt-br/aspnet/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application