Best practice per la mappatura tra dati / business / modello ed ecc

2

Qual è l'approccio migliore alla mappatura tra Entity, View Model o dataContract.

Ad esempio ho visto le seguenti strutture di modellazione per SOA.

WCF - > DataContract distribuito al client.

Livello intermedio - > Modelli e interfacce con quindi mappati al tipo di repository ed eventualmente una classe concreta che implementa un ORM.

In alcuni casi ho visto il riflesso usato, altri solo impostando le proprietà e le librerie di terze parti come AutoMapper per C #.

Qual è il modo più efficace per mantenere il sistema "di facile manutenzione" e funzionale o per i corsi di cavalli?

EDIT: la domanda non era incentrata su Microsoft, ho usato SOA per java e lo stesso problema si è verificato per quanto riguarda la mappatura. Sto chiedendo di mappatura diretta vs riflessione ed ecc.? Non ha niente a che fare con gli ORM.

per es.

    thesolution.models.interfaces
    public interface IProduct { //bundle of properties and method signatures }

    thesolution.models
    public abstract class Product  implements IProduct { //implementation }

    thesolution.repositories.sapMD
    public class Product extends Product implments IProduct { //implements and do stuff}

    thesolution.repositories.sapCRM
    public class Product extends Product implments IProduct { //implements and do stuff}

    thesolution.controllers  
    public class ProductController 
    {
      public IActionResponse Save(IProduct product)
      {
          //save to sapMD repository
          IAction actionMd = ((thesolution.repositories.sapMD.Product)product).Save();

           //save to sapCRM repository
          IAction actionCrm = ((thesolution.repositories.sapMD.Product)product).Save();

          IActionResponse response = new thesolution.message.product.ActionResponse(); 
          response.Actions.Add(actionMd);
          response.Actions.Add(actionCrm);
          return response;
      } 

    }

      thesolution.DataContracts
      //XSD JAXB or etc.


thesolution.Services

//your service method

public class ProductServices ... {

  public thesolution.DataContracts.ResponseAction Save(thesolution.DataContracts.Product product){

    // so now how do you map back to IProduct manually, reflection or etc.

}

}
    
posta Nickz 14.07.2011 - 09:40
fonte

2 risposte

2

Personalmente ho avuto successo con Domain Driven Design (DDD). DDD non è adatto a tutti.

Tuttavia, sospetto che tu stia utilizzando SOA (Service Oriented Architecture), quindi potresti avere una logica aziendale adeguatamente complessa da estrapolare in modo che possa essere modificata indipendentemente dalla tua architettura.

DDD e SOA hanno una specie di simbiosi. Non ho risorse dirette per collegare, tuttavia Udi Dahan fa corsi di formazione sull'utilizzo di DDD & SOA.

Aggiorna : Ecco un video di Udi Dahan che parla dell'utilizzo di DDD con SOA.

risposta data 14.07.2011 - 12:03
fonte
1

Segui il suggerimento.

Se fosse facile, Microsoft non avrebbe inventato così tante scelte. Se sei un "Entity Framework" di Google, ne troverai ancora di più (POCO EF4, ecc.)

Puoi leggere articoli come questo: link

Purtroppo, è difficile perché - probabilmente - Microsoft ha molte politiche interne. Tutti i loro prodotti hanno bisogno di un posto nell'architettura, quindi ci sono molte mappature tra tutti i vari pezzi e parti. È difficile per Microsoft semplificare qualsiasi cosa. (Oracle potrebbe avere lo stesso tipo di problema).

Se ti allontani dalla Microsoft World View, tuttavia, è ancora difficile, ma potrebbe non essere così complesso. Meno prodotti significa meno mappature.

Molte persone usano i database orientati agli oggetti (senza mappature) o strumenti ORM molto semplici (con mappature molto semplici esattamente in un unico punto).

    
risposta data 14.07.2011 - 12:00
fonte

Leggi altre domande sui tag