يجب أن تشترك كائنات طبقة خدمة متعددة في DAO؟

Question

لدي فئة اتصال تحتوي على كائن PortalAccount. عندما أرغب في إنشاء "حساب بوابة" لجهة اتصال، يتم إنشاء حساب عن بعد على تطبيق بوابة باستخدام SOAP / AXIS، ثم يتم ملء PortalAccount لجهة الاتصال ويتم حفظ جهة الاتصال (قاعدة البيانات المحلية تحمل معلومات حول الحساب البعيد، مثل معرف المستخدم واسم المستخدم، إلخ).

لذلك لدي فئة خدمة Portalserviceimpl التي لها طرق لإنشاء مستخدم فعليا على بوابة عن بعد، مع إعطاء مثيل جهة اتصال.

نظرا لجميع هذه المعلومات، سؤولي سؤالي: هل يجب أن يحصل PortalServiceImpl على مثيل كائن ContactDao وقم فعلا بالادخار، أو في حالة إنشاء فئة PortalServiceImpl فقط للمستخدم البعيد، وتعديل كائن جهة اتصال مرت، واترك العميل المسؤول عن الادخار؟

طريقة 1:

class ServiceFacadeImpl {
  public void createPortalAccount(Contact contact) {
    // here the contact is implicitly saved
    this.portalService.createPortalAccount(contact);
  }
}

الطريقة 2:

class ServiceFacadeImpl {
  public void createPortalAccount(Contact contact) {
    // here contact is implicitly modified
    this.portalService.createPortalAccount(contact);
    this.contactDAO.save(contact);
  }
}

كلا الطريقتين تشعر بالخطر بالنسبة لي. الطريقة الأولى يشعر بالخطأ لأن PortalService يقوم بإنشاء مستخدم عن بعد وإنقاذ جهة الاتصال إلى قاعدة البيانات (وإن كان من خلال واجهة DAO). الطريقة الثانية يشعر بالخطأ لأنني يجب أن أفترض أن PortalService هو تعديل جهة الاتصال التي أقطعها إليها.

لدي أيضا شعور بأنني لا أرى بعض Gotchas الأخرى، مثلما لا يحتمل أن لا يتم التعامل مع المعاملات باستمرار.

(راجع للشغل، لقد استخدمت بالفعل كلتا الطريقتين، ولا تريد مواصلة إعادة النظر في دائرة لا نهاية لها. شيء يبدو خطأ هنا.)

Answer 1

هل أنت متأكد من أنها فكرة جيدة أن لديك معرفات اتصال مختلفة محليا وعناية؟ يبدو الخطأ بالنسبة لي، ولكن ربما لا أعرف المجال الخاص بك.

في تطبيقي يتم إرسال جميع جهات الاتصال الجديدة من خلال WebService إلى البوابة البعيدة وحفظها هناك. لذلك، عندما أحفظ جهة اتصال جديدة محليا، يتم إرسالها إلى بوابة عن بعد وحفظها هناك. ربما تحتاج نفس الشيء؟

إذا كانت الأفكار المذكورة أعلاه غير مقبولة بالنسبة لك، فستفعل ذلك مثل هذا:

class ServiceFacadeImpl {
  public void CreatePortalAccountAndSaveContact(Contact contact) {
    try
    {
      contact.portalAccount = this.portalService.createPortalAccount(contact);
      this.contactDAO.save(contact);
    }
    catch(...)
    {
      // do cleanup, for example do you need to delete account from remote 
      // portal if it couldn't be saved locally?
      // If yes, delete it from portal and set contact.portalAccount = null;
    }
  }
}

قد يقول البعض، أن CreatePortalAccountAndSavecontact دون كسر مبدأ مسؤولية واحدة ولكن IMO في هذه الحالة أمر طبيعي تماما لأنه، كما أفهم، فأنت بحاجة إلى هذه العملية لتكون ذرية. حق؟

أو يمكنك إضافة علم منطقي إلى الطريقة، مما يشير إلى ما إذا كنت تريد حفظ جهة الاتصال. ولكن إذا كنت بحاجة دائما إلى حفظ ملامسة portalaccount مباشرة بعد الحصول عليها من البوابة البعيدة - فلن تكون هناك حاجة إلى علامة منطقية.

ملاحظة. لماذا تستخدم الكلمة الرئيسية "هذه"؟ هل العضو الخاص بورتالسرسييس؟ إذا كانت الإجابة بنعم، فربما تحتاج إلى إعادة النظر في اتفاقية تسميةك واسم الأعضاء الخاصين بادئة "_" على سبيل المثال (أعتقد أنها الأكثر شعبية)، مثل _portalservice - ثم سيكون من السهل فهم أن _portalservice هو عضو خاص. آسف للعرود.

حظ سعيد.