I programmatori, quando si tratta di parlare di modelli popolari nelle applicazioni aziendali, predicare che si dovrebbe codificare contro le interfacce per rimuovere forti relazioni tra i componenti; fare ciò aiuterà a cambiare i tipi di cemento riducendo al minimo i cambiamenti in altre aree dell'applicazione. L'ipotesi di fondo è che le interfacce riguardano esclusivamente le astrazioni. Quando si tratta di vita reale è quasi impossibile. Usiamo un esempio:
Diciamo che attualmente utilizzi un framework ORM nella tua applicazione, che hai sottratto applicando il pattern del repository. Ora, puoi veramente cambiare il framework ORM senza problemi?
public interface IRepository<T>
{
T GetById(int id);
void Add(T entity);
void Remove(T entity);
void Update(T entity);
IQueryable<T> Query(Expression<Func<T, bool>> filter);
}
In teoria, questa implementazione può essere applicata al resto dell'applicazione, ma restano molte domande sull'applicazione effettiva di questo modello:
- In che modo questo schema mi protegge dal processo interno delle librerie?
- In che modo l'astrazione si occupa della variazione delle eccezioni generate da ciascuna libreria?
- Se ho selezionato un ORM che fornisce internamente un meccanismo di memorizzazione nella cache e in seguito decido di passare a un ORM alternativo privo di tale supporto, come lo gestisce questo modello?
Quindi, da questo, credo che l'architettura del progetto sia strongmente influenzata dalle librerie che vengono utilizzate. c'è qualcosa di sbagliato con questo? Sto assumendo troppo da questo modello?