L'architecture de projet a-t-elle une relation étroite avec les bibliothèques d'occasion?

Question

Les programmeurs, lorsqu'il s'agit de parler des modèles populaires dans les applications d'entreprise, prêchez que vous devez coder contre les interfaces pour supprimer les relations fortes entre les composants; Cela aidera à modifier les types de béton tout en minimisant les changements dans d'autres domaines de l'application. L'hypothèse sous-jacente est que les interfaces concernent toutes les abstractions. En ce qui concerne la vraie vie, c'est presque impossible. Permet d'utiliser un exemple:

Disons que vous utilisez actuellement un framework ORM dans votre application, que vous avez résumé en appliquant le modèle de référentiel. Maintenant, pouvez-vous vraiment changer le cadre ORM de manière transparente?

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);                                
} 

Théoriquement, cette implémentation peut être appliquée au reste de l'application, mais de nombreuses questions demeurent sur l'application réelle de ce modèle:

1. Comment ce modèle me protège-t-il du processus interne des bibliothèques?
2. Comment l'abstraction traite-t-elle de la variation des exceptions lancées par chaque bibliothèque?
3. Si j'ai sélectionné un ORM qui fournit un mécanisme de mise en cache en interne et que je décide plus tard de passer à un ORM alternatif sans un tel support, comment le modèle gère-t-il cela?

Donc, à partir de cela, je crois que l'architecture du projet est fortement influencée sur les bibliothèques utilisées. Y a-t-il quelque chose de mal à cela? Est-ce que je suppose trop de ce modèle?