mef vs dynamic class loading from configuration

השבוע יצא לי להשתתף ב architecture design review בו הוצג פיתרון לבעיה הבאה:

תיאור הבעיה

מרחב הבעיה הנו מערכת לעיבוד אות וידאו הכתובה ב dot net אשר צריך לממש בה את החיבור למקורות וידיאו שונים .

הארכיטקטורה נדרשת להגדיר את החיבור בין assembly שמכיל אלגוריתם לעיבוד וידיאו ל assembyמתאם למצלמה .כאשר יש דרישה שאהיה decoupling בין שני הassemblies נוכל להחליף את המתאם המצלמה הנוכחי במתאם אחר מבלי לשנות דבר בassembly של עיבוד הוידאו .

ארכיטקטורת הפתרון המוצא

ארכיטקטורת הפתרון שהוצגה התבססה על שימוש ב microsoft mef על מנת לבצע את החיבור בין ה assembles

  [Export(typeof(ICameraControl))]   
  public class CameraTypeBAdapter : ICameraControl   
  { 
         public byte [] GetNextFrame() 
         {
                 return theNextFrame;      
         } 
   }

בצד של ה client

class CameraController
{
    [Import(typeof(ICameraControl))]
    public ICameraControl CameraControl { get; set; }

    public void Init()
    {
        try
        {
            AggregateCatalog aggregatecatalogue = new AggregateCatalog();

            aggregatecatalogue.Catalogs.Add(new DirectoryCatalog(
                AppDomain.CurrentDomain.BaseDirectory));

            CompositionContainer container = new CompositionContainer(
                aggregatecatalogue);
            container.ComposeParts(this);

        }

        catch (CompositionException cex)
        {
            Console.WriteLine(cex.Message);
        }
    }

    public byte[] GetNextFrame()
    {
        return CameraControl.GetNextFrame();
    }
}

נדרש שה server לא יהיה singleton דבר אשר יכול להישלט על ידי attribute של

[PartCreationPolicy (CreationPolicy.NonShared)]

על הclass של ה server.

בחינת ה Domain של הבעיה מראה שכרגע קימות שתי מצלמות שצריך לתמוך בהן לא הוגדר שבעתיד יצטרכו לתמוך במצלמת אחרות וההחלטה לבנות תשתית שתתמוך בתהליך כזה התבשלה אצל המפתחים של הפרויקט האפשרות שבאתר ה production כל מה שיצטרכו לעשות על מנת להחליף סוג מצלמה זה להחליף dll לא היתה חלק מה domain .

לפעמים מפתחים מכניסים תשתיות שאין בהן צורך. הדבר מייקר ומסבך את הפיתרון סתם.

באותה מידה יכלו המפתחים להחליט שהחלפת המצלמה תהייה on the fly .חשוב ב desgins review לרדת לעומקו של מרחב הdomain של הבעיה אותה מנסים לפתור לפני שצוללים לפתרון ברמה טכנולוגית .

ההמלצה שלי

אין כל סיבה כאן לשימוש במיקרוסופט mef אשר תסבך את הארכיטקטורה .

mef לא נותנת כאן ערך מוסף לפתרון אלא רק מגבילה אותו :

1.לא נוכל להפיץ שני adapters במקביל באותו bungle של assemblies .
2.שליטה על תהליך ה יצירה של ה class ים הנו מוגבל ב mef

לפי דעתי שימוש ב קונפיגורציה להצבעה על ה assembly וה type הנה פתרון פשוט וגמיש יותר .
מבחינת ביצועים לא צריכה להתבצע סריקה של כל ה type במערכת על מנת לבצע את הקישור בין ה client והserver
כמו כן מתן אפשרות שליטה למשתמש המערכת לבחור את הקונפיגורציה הרצויה יותר פשוטה .
מפתח המערכת צריך להכניס קוד שקורא מקונפיגורציה את ה assembly וה type וליצור את ה class זה לא קוד מורכב או מסובך .

spring framework לפי דעתי נותנת כלים טובים ופשוטים לפתרונות בעיות אילו
דוגמה בspring לפתרון הבעיה

 <bean id="CameraControl" class="com.zvika.camera.services.CameraControlB">
           
 </bean>

הקוד לטעינת ה bean

ConfigurableApplicationContext context = 
            new ClassPathXmlApplicationContext(new String[] {"Camera-Adapter.xml"});
    

ICameraControl theCameraControl = (ICameraControl)context.getBean("CameraControl");
        
theCameraControl.GetNextFrame ();