partage Entity Framework entre Azure Cloud Services

Question

Actuellement je un Windows Azure Cloud Service Project (Service1) qui va mettre des messages dans une file d'attente de stockage (pour être tiré par un autre service en nuage), puis tirez plus tard des messages d'un stockage différent queue. En fonction des messages reçus par ce service, un objet peut être ajouté à une base de données SQL Azure. Jusqu'à présent, j'ai ajouté au travail de la file d'attente, et j'ai créé une bibliothèque de service qui contient l'Entity DataModel pour la base de données SQL qui, jusqu'à présent, n'a qu'une seule table, tblCustomers. Ce projet a un rôle Web pour afficher les clients entrants, et un rôle de travailleur pour envoyer les clients à un autre service pour la procédure de traitement. Je sérialise un objet client en XML en utilisant XMLSerializer, et envoie ce message xml à la file d'attente. Code sérialisation:

//Serialize Lead to XML 
      StringBuilder sbLead = new StringBuilder(); 
      var serializer = new XmlSerializer(typeof(Lead)); 
      using (var writer = XmlWriter.Create(sbLead)) 
      { 
       serializer.Serialize(writer, objLead); 
      } 
      String xml = sbLead.ToString(); 

      //Create and send message 
      var message = new CloudQueueMessage(xml); 
      clarityQueue.AddMessage(message); 

Entité Client Objet Définition:

public partial class Customer 
    { 
     public int ID { get; set; } 
     public string FirstName { get; set; } 
     public string MiddleName { get; set; } 
     public string LastName { get; set; } 
     public string AddressLine1 { get; set; } 
     public string AddressLine2 { get; set; } 
     public string ZipCode { get; set; } 
     public string EmailAddress { get; set; } 
     public string HomePhone { get; set; } 
     public string CellPhone { get; set; } 
     public string SSN { get; set; } 
     public string DateOfBirth { get; set; } 
     public string IDState { get; set; } 
     public string IDNum { get; set; } 
     public string Status { get; set; } 
     public Nullable<System.DateTime> DateCreated { get; set; } 
     public Nullable<System.DateTime> DateApproved { get; set; } 
    } 

Maintenant je dois tirer ce message de la file d'attente avec un autre service (Service2) et désérialiser. Le problème est que, dès maintenant, Service2 n'a aucune idée de la manière de désérialiser le Lead, car il ne sait pas comment un lead est structuré. Je comprends que je pourrais ajouter la DLL de service de service1 dans le service 2, et mon problème serait résolu, mais alors je dois copier sur une DLL chaque fois que l'Entity Framework change, ce qui sera probablement assez souvent. Je pense que d'avoir un modèle séparé de l'entité dans les deux projets est une mauvaise pratique, mais je ne me sens pas aussi comme une bibliothèque de services WCF est appropriée parce que je aurais besoin le service Cloud, et le service WCF à la fois en cours d'exécution, et à ce moment-là je pourrais ainsi faire de l'ensemble du projet un service WCF. Et ce n'est pas le but.

Ma question est, quelle est la meilleure pratique pour l'utilisation d'objets d'entités dans plusieurs solutions différentes (Service1 et Service2 doivent être dans des solutions séparées)? J'ai l'impression que c'est un problème assez commun, mais après avoir passé par le kit de formation Azure, et la recherche en ligne pendant des heures, je n'ai rien trouvé.

EDIT: Pour éclaircir les choses, Tout ce que je cherche est un moyen d'envoyer un objet Entité d'un service de nuage d'azur à un autre en utilisant Queues de stockage. C'est-à-dire Envoyer un objet client à partir de Service1 vers un StorageQueue, puis extraire le même objet client à partir de ce StorageQueue à l'aide de Service 2. Les services sont dans deux solutions distinctes. J'ai besoin de savoir comment définir Client (qui est un objet représenté par une table dans une base de données) dans Service1 et Service2

Answer 1

Une approche consiste à avoir un projet séparé qui contiendrait les classes Entity, plus d'autres choses (comme par exemple, si votre projet s'appelle "MyService", vous auriez 3 projets: MyService, MyService.FrontEnd, MyService.Worker. Le code des entités de la base de données serait dans MyService et les deux autres projets incluraient ce projet comme référence (ne naviguez pas dans le dossier bin et ajoutez le fichier .dll comme référence.) Visual Studio vous permet de référencer d'autres projets dans la même solution. De cette façon, vous n'avez pas besoin de copier la DLL ou de générer des problèmes de synchronisation lorsque l'ordre de construction est incorrect)

C'est l'approche que j'utilise depuis plusieurs années sur plusieurs projets cloud.