Almacenamiento abstracto de datos para la clase según el entorno (web / windows)

Question

Tengo una clase y el almacenamiento de su información dependerá de si está siendo consumida por una aplicación web o de Windows. Iba a usar el patrón de fábrica para distribuir el objeto correcto. Supongo que la persona que llama almacenaría ese objeto de manera apropiada si no quisiera recrear el objeto. ¿Alguien tiene otras sugerencias para abstraer el almacenamiento de datos basado en la plataforma?

Por ejemplo, quiero almacenar datos como variables locales cuando son invocados por la aplicación de Windows (enviando la subclase apropiada) y guardar en la sesión cuando son invocados por la aplicación web.

Answer 1

Como dice sgreeve, la separación de preocupaciones es algo a tener en cuenta para obtener un código que se pueda mantener.

Utilizando una idea de repositorio, la aplicación Winform y la aplicación web podrían inyectar su propio proveedor de almacenamiento. Esos proveedores podrían compartir una lógica común si es necesario por herencia o composición.

public class MyClassRepository
{
    IStorageProvider _provider;
    public MyClassRepository(IStorageProvider provider)
    {
        _provider = provider;
    }

    public void Save(MyClass o)
    {
        _provider.Save(o);
    }

    public MyClass GetBy(string id)
    {
        return _provider.GetBy(id);
    }
}

La aplicación Winforms invocaría el almacenamiento a través de:

var provider = new WindowsStorageProvider();
var rep = new MyClassRepository(provider);
rep.Save(myClassObject);

y la aplicación web:

var provider = new WebStorageProvider();
var rep = new MyClassRepository(provider);
rep.Save(myClassObject);

Answer 2

No me parece que el patrón Factory sea una solución al problema que tienes. El patrón Factory está destinado a proporcionar una instancia de un subtipo particular de una clase, protegiendo a la persona que llama de la fábrica de (a) el subtipo real que se devuelve, y (b) la lógica que la fábrica utilizó para decidir qué subtipo devolver.

Esto no es lo que necesitas aquí. Creo que debe abstraer el almacenamiento de los datos fuera de la clase que modela los datos que se almacenan.

Tiene una clase común a dos aplicaciones, y cada una de esas aplicaciones debe implementar la funcionalidad para almacenar los datos encapsulados por su clase de una manera apropiada para esa aplicación. Eso implica dos cosas:

1. Cada aplicación (formulario web y Windows) debe contener funcionalidad para almacenar datos, pero ninguno necesita incluir el código utilizado por el otro. p.ej. la aplicación de formularios de Windows no necesita saber cómo almacenar datos en una sesión web. Por lo tanto, el código que almacena los datos en una sesión web debe estar en un objeto que sea parte de la aplicación web pero no de la aplicación de formularios de Windows, y viceversa.

2. Dado que este es el caso, y dado que la clase cuyos datos está almacenando tiene que ser común a ambas aplicaciones, esa lógica de almacenamiento no puede ser parte de esa clase. (Siguiendo los principios de diseño OO aceptados, esa clase no debería saber cómo almacenarse en diferentes partes de su aplicación de todos modos, ya que eso introduce dependencias que dificultan los cambios futuros. Consulte Principio de responsabilidad única ...)

Espero que esto sea útil