Il modello Factory è buono per questa situazione?

Il vero problema è che la distribuzione di un'applicazione è incapsulata da una classe specifica per ogni applicazione, che richiede modifiche al codice dell'applicazione e del database.

Per prima cosa è necessario rompere ogni distribuzione in una serie di passaggi (Erik Eidt ha accennato a questo, ma non è andato abbastanza lontano). Quindi identifica un'astrazione chiara per ogni passaggio.

Ad esempio, è necessario spostare i file da una posizione di gestione temporanea a un server. Definisci un passaggio (e una classe) che esegue questo passaggio, dati l'origine e la destinazione, oltre alle credenziali di accesso se necessario.

Altre fasi possono essere astratte in termini generali, come eseguire script di shell o effettuare chiamate ai servizi API.

Nessuna singola applicazione dovrebbe essere la sua classe. Potrebbe essere una classe chiamata "ApplicationDeployment" che ha una serie di passaggi. Le informazioni specifiche per ogni passaggio devono essere conservate in una o più tabelle in un database o in un archivio di file flat.

Lo schema di fabbrica è ancora applicabile a questo problema se lo si utilizza per generare istanze concrete di una sorta di "passaggio" in un processo di distribuzione dell'applicazione.

Il problema si trova con ogni applicazione che richiede una classe personalizzata e modifiche al database.

Generalmente, ogni volta che ricostituisci un oggetto (con metodi) da un database, dovrai utilizzare il modello di fabbrica in un modo o nell'altro.

Poiché non è possibile memorizzare l'oggetto stesso, è necessario indicare al codice quale oggetto creare e il codice "stringa su oggetto" è il cuore dell'oggetto factory.

Tuttavia, non è l'unico modo di fare le cose. Ad esempio potresti avere un oggetto come

Applicazione di classe {     Elenca i passaggi {get; set;} }

e un numero di classi StepProcessor con la logica per eseguire diversi passaggi

Ora, creo sempre uno dei singoli processori step del mio programma e inviamo ogni passaggio al suo processore corrispondente.

Non ho più bisogno di una fabbrica di per sé, Step è solo una classe di dati senza logica e i processori vengono sempre istanziati.

A prima vista potrebbe esserci un accoppiamento non necessario. Per aggiungere una nuova applicazione, è necessario aggiungere una riga al database e quindi modificare il codice in più punti: innanzitutto, è necessario aggiungere una nuova classe che supporti l'interfaccia e quindi, in secondo luogo, modificare il codice ApplicationFactory per collegare la stringa del nome dell'applicazione alla nuova classe.

Una soluzione più generica potrebbe richiedere solo l'aggiunta (la riga db e) della nuova classe. Ciò potrebbe basarsi su una convenzione di denominazione e una riflessione per cercare la classe appropriata per nome. In alternativa, si potrebbe avere un file di configurazione esterno o altra voce nel database che associa i nomi delle applicazioni ai nomi delle classi.

In tali schemi, la classe poteva essere spostata in una DLL caricata esternamente e le nuove DLL specifiche dell'app potevano essere create senza modificare l'applicazione principale che contiene la fabbrica.

Tuttavia, per aggiungere una nuova app, è necessario aggiungerla al database e distribuire anche la DLL. La distribuzione della DLL potrebbe non offrire nulla oltre la distribuzione di una nuova copia del factory contenente l'applicazione. D'altra parte, questo accoppiamento più lento può consentire a diversi autori di contribuire (sviluppare, testare e distribuire) DLL di codice per nuove app senza modificare il codice sorgente principale.