TypeConverter , what is it? and how we can use it?

כל מפתח שכתב Xaml נתקל בבעיה הבאה:

Property מסוג bool שעושים לו binding ל visibility של אלמנט כלשהוא.

הפיתרון לבעיה הזאת פשוט מאוד ולכן בכל תוכנה שכתובה ב xaml תמצאו את השורה הבאה:

 Visibility="{Binding IsVisible, Converter={StaticResource BoolToVisibilityConverter}

יצירת converter  היא באמת הפיתרון המתבקש כאן ,

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

בעצם הבעיה היא ש Visibility Property לא יודע לתרגם את הטיפוס שהוא מקבל לטיפוס Visibility (שהוא במקרה שלנו enum).

פעולת התרגום מתבצעת על ידי Type conversion בצורה הבאה:

על כל טיפוס שאנו מעוניינים שהוא יהיה מסוגל לטפל בטיפוסים אחרים אנו שמים TypeConverterAttribute.(אפשר לשים ברמת הclass או ברמת הproperty)

TypeConverterAttribute מקבל פרמטר  אחד , מחלקה אשר יודעת לבצע את התירגום שאנו מבקשים.

לדוגמא:

 [TypeConverter(typeof(VisibleTypeConverter))]

        public Visibility Visible

        {

            get

            {

                return (Visibility)this.GetValue(VisibleProperty);

            }

            set

            {

                this.SetValue(VisibleProperty, value);

            }

        }

 public class VisibleTypeConverter : TypeConverter

    {

{                                                             

לכן מה שהיינו מצפים שיהיה ב Visibility property הוא TypeConverter שיודע לתרגם  "true"/"false" לערך הרצוי.

דוגמא טובה לכך היא שימוש ב margin,

Margin  מקבל Thinckness struct , אז איך הוא יודע לתרגם את הדבר הבא ",0,2,2,1" ?

ובכן , כך זה נראה ב reflector :

[TypeConverter(typeof(ThicknessConverter)]

  public struct Thickness : IEquatable<Thickness>

ומעתה , כל מי שישתמש ב thickness  מקבל קיצור דרך לשימוש ב  property !

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

טוב, אז אם לא הצעתי פיתרון לבעיה , מה בעצם באתי להגיד פה?

ובכן, כמו שהזכרתי קודם, אנו צריכים ללמוד מהמקרה הזה, שכשאנחנו כותבים user control משלנו שנועד לשימוש בכמה וכמה מקומות במערכת, תמיד לחשוב על מי שצריך להשתמש בו, אפשר להכניס typeConverter  שימיר "2,8"Grid = ליצירת Grid עם 2 עמודות ו 8 שורות למשל .

אולי בהמשך אתן דוגמאות בנושא.

.

UIElement Background = Null VS. Transaprent

כמו שכל מפתח WPF/Silverlight מכיר , Background property יכול לקבל 2 ערכים מאוד דומים:

Null

Transparent

לכאורה, למה צריך את שניהם? אם Null נותן לי צבע שקוף  למה אני צריך Transparent ?

ובכן, יש הבדל...

כשאתם משתמשים ב Transparent  תחשבו כאילו יש מסך זכוכית שקופה באלמנט שלכם ולכן כל לחיצה עליו תורגש ע"י האירועים המתאימים ((mouse events.

לעומת זאת ב Null  אין שום דבר באלמנט שאפשר לגעת בו, ולכן שום  אירוע לא ייתפס בו.

Unity VS. MEF , Choosing the right DI container for your client application

When we need to choose for a DI framework for our client system,

We will probably have to choose between the two main frameworks available,

Unity and MEF.

For start I have to say that both of them are good frameworks, and every one of them has its advantages.

First, let's make it clear, both of them allow you to define containers that you can register with classes, and later on inject them. Both of them will take care of initializes the classes before you will use them.

Let's talk about the special features every one of them has:

MEF:

·         If your system is going to have a lot of plugins/extensions in its lifetime, MEF provides a great platform to work with. The mechanism of MEF will search for all the extensions that expose the predefined interface and will import them to your desired place. It is very convenient way to work with.

The downside for this feature is that you can't work with POCO objects,why is that?

Because you have to put attributes on the classes that you want to export and import. So if you are dealing with closed assembly that is not predefined as MEF expected , you have a problem.

·         The Attributes mechanism of MEF let you query  your desired classes with a variety of combination as you need, just declare your attributes (many as you wish) and import them with your desired filtering.

UNITY:

·         Unity works in a more obvious way, you call the container and ask the desired class. If you registered this class to the container , you will get it by your demand. MEF mechanism works with attributes so it is less intuitive way, and again need a control on every class you need to use.

·         Unity support interception, that mean that you can define a method that will be called before or after the injection of the class (for logging etc.). MEF don’t have this ability.

Like I mentioned above , these are a great frameworks to use for IoC and DI.

Just pay attention to the advantages of each of them so you could choose the framework that is right for you.