Alternative à SQLAlchemy ORM reconstructor

Question

Je travaille actuellement sur une petite application en Python (3.6) capable de gérer des portefeuilles de titres, et d'en faire une analyse financière.

Les fonctionnalités sont simplement une interface CRUD (Créer, Lire, Mettre à jour, Supprimer) pour mes portefeuilles et actions. Ils peuvent être conservées dans un dabase (en utilisant PostgreSQL et SQLAlchemy comme ORM)

La chose est, je visais d'avoir un découplage absolu entre:

• La « logique métier » (situé dans un package core), où je mes objets python Stock, Portfolio, Regression, etc.
• la « couche de persistance », (situé dans un paquet séparé database), où toutes les métadonnées de SQLAlchemy et la mise en correspondance avec les objets de l'emballage core sont def INED

Je veux cette séparation pour plusieurs raisons: d'abord, je veux être en mesure de lancer le paquet core en mode autonome (avec ni aucune DB installé ni même SQLAlchemy) et, d'autre part, je pense qu'il est une bonne pratique, parce que dans mon paquet core, je peux vraiment se concentrer sur l'analyse et ne « polluer » mes objets Python avec le SQLA Column, relationships, etc.

j'ai réussi à le faire jusqu'à présent, en utilisant le SQLAlchemy bas niveau mapper et Table. Cependant, il y a un seul point que je ne peux pas comprendre. Actuellement, mon objet Python Stock est comme:

class Stock: 

    def __init__(self, ticker: str, exchange: Exchange, name: str=None): 
     self.ticker = ticker 
     self.exchange = exchange 
     self.name = name 
     self._data = None 

    ... 

La propriété _data est nécessaire pour stocker mes données financières, et je veux instancier.

Mais, comme vous le savez, quand je charge une Stock de la base de données, (dans le cas où je l'utilise en fait le database pkg), par exemple via une commande comme session.query(Stock).first(), la fonction __init__ est pas appelée par SQLA . La seule chose que je peux faire est d'ajouter une fonction:

@orm.reconstructor 
def init_on_load(self): 
    self._data = None 

où orm est sqlalchemy.orm et est le seul importation de sqlalchemy dans mon core pkg. Je voudrais m'en débarrasser!

Est-ce que quelqu'un a une idée? Par exemple, il existe peut-être un moyen d'instancier la propriété _data à l'intérieur du package database, via le mapper, mais je n'en sais pas.

Merci

Answer 1

EDIT:

Réponse au commentaire, « datamapper n'instrusive donc vous pouvez utiliser une classe de données sur votre couche de données et la couche d'affaires ». Ce n'est vrai que si le projet est petit. mais lorsque les projets prennent de l'ampleur, le magasin de données sous-jacent ne change pas au même rythme que votre logique métier. Ensuite, vous avez besoin de couches intermédiaires, par exemple des adaptateurs, des transformateurs, etc.Quoi qu'il en soit, si votre problème ne concerne pas le découplage, il suffit de le faire fonctionner, puis utilisez le @ orm.reconstructor ou n'importe quel hacks. Sinon, utilisez le moins de hacks ou la solution de contournement possible.

======================================

Sur la base de mon expérience , Les classes ORM sont couplées avec le framework OMR sous-jacent, quel que soit le framework choisi, SQLAlchemy, MongoEngine, etc.

Si vous souhaitez extraire le stockage de données et pouvoir changer de moteur de données à l'avenir. Ensuite, mieux écrire votre logique d'entreprise de base sur certaines classes ordinaires. Ensuite, dans le module de stockage, fournissez une fonction pour convertir la classe ORM en classe simple.

par exemple

# module core.objects 
class Stock: 
    def __init(self, name, price): 
     self.name = name 
     self.price = price 

# business logic 
class BusinessLogic: 
    @staticmethod 
    def logic(stocks: list[Stock]): 
     pass 

Ensuite, dans le paquet de stockage

from core.objects import Stock as CoreStock 
# This is the ORM dependent class 
class Stock(Model): 
    name = columns.Text() 
    price = columns.Float() 

    @classmethod 
    def to_core_objects(instances): 
     return [CoreStock(instance.name, instance.price) for instance in instances] 

Maintenant, vous pouvez facilement changer de moteurs de stockage, mysql, csv etc, et beaucoup plus facile d'écrire des tests unitaires.