INotifyPropertyChanged กับ DependencyProperty ใน ViewModel

เมื่อติดตั้ง ViewModel ในแอพพลิเคชั่น WP-View-ViewModel สถาปัตยกรรม WPF ดูเหมือนจะมีสองตัวเลือกหลัก ๆ ในการทำให้ databindable ฉันได้เห็นการใช้งานที่ใช้DependencyPropertyสำหรับคุณสมบัติที่วิวจะเชื่อมโยงกับและฉันได้เห็นการใช้งาน ViewModel INotifyPropertyChangedแทน

คำถามของฉันคือเมื่อใดที่ฉันควรเลือกหนึ่งคำถาม มีความแตกต่างด้านประสิทธิภาพหรือไม่? เป็นความคิดที่ดีหรือไม่ที่จะมอบการพึ่งพา ViewModel ให้กับ WPF? ฉันต้องพิจารณาอะไรอีกเมื่อตัดสินใจออกแบบ

เคนท์เขียนบล็อกที่น่าสนใจเกี่ยวกับหัวข้อนี้: ดูโมเดล: POCOs เมื่อเทียบกับ DependencyObjects

สรุปสั้น ๆ:

1. DependencyObjects ไม่ได้ถูกทำเครื่องหมายเป็นซีเรียลไลซ์
2. คลาส DependencyObject จะแทนที่และผนึกเมธอด Equals () และ GetHashCode ()
3. DependencyObject มีความสัมพันธ์ของเธรด - สามารถเข้าถึงได้บนเธรดที่สร้างขึ้นเท่านั้น

ฉันชอบวิธีการ POCO คลาสพื้นฐานสำหรับ PresentationModel (aka ViewModel) ซึ่งใช้อินเทอร์เฟซ INotifyPropertyChanged สามารถพบได้ที่นี่: http://compositeextensions.codeplex.com

ตามคู่มือประสิทธิภาพ WPF DependencyObjects ทำงานได้ดีกว่า POCO ที่ใช้ INotifyPropertyChanged แน่นอน:

http://msdn.microsoft.com/en-us/library/bb613546.aspx

ตัวเลือกขึ้นอยู่กับตรรกะทางธุรกิจของคุณและระดับนามธรรม UI หากคุณไม่ต้องการการแยกที่ดี DP จะทำงานให้คุณ

DependencyProperties จะมีผลบังคับใช้เป็นหลักในระดับ VisualElements ดังนั้นมันจะไม่เป็นความคิดที่ดีถ้าเราสร้าง DPs จำนวนมากสำหรับความต้องการทางธุรกิจแต่ละอย่างของเรา นอกจากนี้ยังมีค่าใช้จ่ายสำหรับ DP ที่สูงกว่า INotifyPropertyChanged เมื่อคุณออกแบบ WPF / Silverlight พยายามออกแบบ UI และ ViewModel แยกกันโดยสิ้นเชิงเพื่อให้ ณ เวลาใด ๆ เราสามารถเปลี่ยนการควบคุมเค้าโครงและ UI (ขึ้นอยู่กับธีมและสไตล์)

โปรดดูโพสต์นี้ - /programming/275098/what-applications-could-i-study-to-understand-datamodel-view-viewmodel ลิงก์มีการอ้างอิงถึงรูปแบบ Model-View-ViewModel ซึ่งมีความเกี่ยวข้องกับการสนทนานี้มาก

INotifyPropertyChangedจากมุมมองการแสดงออกผมอย่างทั่วถึงเพลิดเพลินกับการใช้คุณสมบัติพึ่งพาและประจบประแจงที่คิดของ นอกเหนือจากstringชื่อคุณสมบัติและการรั่วไหลของหน่วยความจำที่เป็นไปได้เนื่องจากการสมัครสมาชิกเหตุการณ์INotifyPropertyChangedเป็นกลไกที่ชัดเจนมากขึ้น

คุณสมบัติการพึ่งพาหมายถึง "เมื่อทำสิ่งนี้" โดยใช้ข้อมูลเมตาแบบคงที่ที่เข้าใจง่าย มันเป็นวิธีการประกาศที่ได้รับการลงคะแนนของฉันเพื่อความสง่างาม

INotifyPropertyChanged เมื่อใช้ยังช่วยให้คุณสามารถเพิ่มตรรกะเพิ่มเติมในรหัสของ getters และ setter ของคุณสมบัติของคุณ

DependencyProperty ตัวอย่าง:

public static DependencyProperty NameProperty = DependencyProperty.Register( "Name", typeof( String), typeof( Customer ) );

public String Name
{
    set { SetValue( NameProperty, value ); }
    get { return ( String ) GetValue( NameProperty ); }
}

ใน getter และ setter ของคุณ --- สิ่งที่คุณทำได้เพียงแค่เรียก SetValue และ GetValue ตามลำดับ b / c ในส่วนอื่น ๆ ของเฟรมเวิร์กที่ getter / setter ไม่ถูกเรียกใช้แทนมันจะเรียก SetValue, GetValue โดยตรงดังนั้นตรรกะคุณสมบัติของคุณจะไม่ ดำเนินการอย่างน่าเชื่อถือ

ด้วยINotifyPropertyChangedกำหนดกิจกรรม:

public event PropertyChangedEventHandler PropertyChanged;

และจากนั้นก็มีตรรกะใด ๆ ในรหัสของคุณแล้วโทร:

// ...
// Something cool...
// ...

if( this.PropertyChanged != null )
{
    PropertyChanged( this, new PropertyChangedEventArgs( "Name" ) );
}

// More cool stuff that will reliably happen...

สิ่งนี้อาจอยู่ใน getter / setter หรือที่อื่น ๆ

คุณสมบัติการพึ่งพามีไว้เพื่อรองรับการเชื่อมโยง (เป็นเป้าหมาย) ในองค์ประกอบ UI ที่ไม่ได้เป็นแหล่งข้อมูลผูกพันนี่คือที่ INotifyProperty เข้ามาจากมุมมองที่บริสุทธิ์ที่คุณไม่ควรใช้ DP ใน ViewModels

"เพื่อเป็นแหล่งของการเชื่อมโยงคุณสมบัติไม่จำเป็นต้องเป็นคุณสมบัติการพึ่งพาคุณสามารถใช้คุณสมบัติ CLR ใด ๆ เป็นแหล่งข้อมูลการเชื่อมโยงอย่างไรก็ตามเพื่อให้เป็นเป้าหมายของการเชื่อมโยงคุณสมบัติต้องเป็น คุณสมบัติการพึ่งพาสำหรับการโยงทางเดียวหรือสองทางเพื่อให้มีผลบังคับใช้คุณสมบัติแหล่งข้อมูลต้องสนับสนุนการแจ้งเตือนการเปลี่ยนแปลงที่เผยแพร่ไปยังระบบการเชื่อมโยงและทำให้เป็นเป้าหมายสำหรับแหล่งการรวม CLR ที่กำหนดเองซึ่งหมายความว่า คอลเล็กชันควรสนับสนุน INotifyCollectionChanged "

วัตถุการอ้างอิงทั้งหมดไม่สามารถต่อเนื่องกันได้ (ซึ่งอาจขัดขวางการใช้ ViewModels และ DTO (POCO)

มีความแตกต่างระหว่าง DP ภายใน Silverlight เมื่อเปรียบเทียบกับ WPF

http://msdn.microsoft.com/en-us/library/cc221408(v=VS.95).aspx

http://msdn.microsoft.com/en-us/library/cc903933(VS.95).aspx

ฉันก็ต้องพิจารณาการตัดสินใจนี้เมื่อเร็ว ๆ นี้

ฉันพบว่ากลไก INotifyPropertyChanged เหมาะสมกับความต้องการของฉันดีกว่าเพราะมันทำให้ฉันสามารถยึด GUI กับกรอบตรรกะทางธุรกิจที่มีอยู่โดยไม่ต้องทำซ้ำ เฟรมเวิร์กที่ฉันใช้มีรูปแบบผู้สังเกตการณ์ของตัวเองและง่ายต่อการแจ้งเตือนระดับหนึ่งไปยังอีกระดับหนึ่ง ฉันมีคลาสที่ใช้อินเทอร์เฟซผู้สังเกตการณ์จากกรอบงานตรรกะทางธุรกิจของฉันและอินเทอร์เฟซ INotifyPropertyChanged

ด้วย DP คุณไม่สามารถกำหนดแบ็กเอนด์ที่จัดเก็บสถานะของคุณเองได้ ฉันจะต้องให้. net แคชสำเนาของทุกรายการของรัฐที่ฉันผูกพัน ดูเหมือนว่าค่าใช้จ่ายที่ไม่จำเป็น - รัฐของฉันใหญ่และซับซ้อน

ดังนั้นที่นี่ฉันพบ INotifyPropertyChanged ดีกว่าสำหรับการเปิดเผยคุณสมบัติจากตรรกะทางธุรกิจไปยัง GUI

อย่างที่บอกไปแล้วว่าฉันต้องการวิดเจ็ต GUI แบบกำหนดเองเพื่อเปิดเผยคุณสมบัติและสำหรับการเปลี่ยนแปลงคุณสมบัตินั้นเพื่อส่งผลกระทบต่อวิดเจ็ต GUI อื่น ๆ DP พิสูจน์วิธีแก้ปัญหาง่ายๆ

ดังนั้นฉันจึงพบว่า DP มีประโยชน์สำหรับการแจ้งเตือน GUI เป็น GUI

เป็นความคิดที่ดีหรือไม่ที่จะมอบการพึ่งพา ViewModel ให้กับ WPF?

.NET 4.0 จะมี System.Xaml.dll ดังนั้นคุณไม่จำเป็นต้องพึ่งพาเฟรมเวิร์กใด ๆ เพื่อใช้งาน ดูโพสต์ของ Rob Relyeaเกี่ยวกับเซสชัน PDC ของเขา

ของฉัน

XAML เป็นภาษาสำหรับอธิบายวัตถุและ WPF เป็นกรอบงานซึ่งวัตถุที่อธิบายเป็นองค์ประกอบ UI

ความสัมพันธ์ของพวกเขาคล้ายกับ C # ซึ่งเป็นภาษาสำหรับอธิบายตรรกะและ. NET ซึ่งเป็นกรอบที่ใช้ตรรกะชนิดใดชนิดหนึ่งโดยเฉพาะ

วัตถุประสงค์ของ XAML คือกราฟวัตถุที่เปิดเผย เทคโนโลยี W * F เป็นตัวเลือกที่ยอดเยี่ยมสำหรับกระบวนทัศน์นี้ แต่ XAML มีอยู่เป็นอิสระจากพวกเขา

XAML และระบบการพึ่งพาทั้งหมดถูกนำมาใช้เป็นสแต็คแยกต่างหากสำหรับ WF และ WPF ซึ่งอาจใช้ประโยชน์จากประสบการณ์ของทีมที่แตกต่างกันโดยไม่ต้องสร้างการพึ่งพา (ไม่มีการเล่นสำนวนเจตนา) ระหว่างพวกเขา

คุณสมบัติการพึ่งพาเป็นกาวของการสร้างการควบคุมที่กำหนดเอง หากคุณสนใจที่จะใช้ Intelli-sense เพื่อแสดงคุณสมบัติของคุณในหน้าต่างคุณสมบัติในเวลาออกแบบ XAML คุณต้องใช้คุณสมบัติการพึ่งพา INPC จะไม่แสดงคุณสมบัติใด ๆ ในหน้าต่างคุณสมบัติขณะออกแบบ

ดูเหมือนว่าควรใช้คุณสมบัติการพึ่งพาในการควบคุมที่คุณสร้างเช่นปุ่ม ในการใช้คุณสมบัติใน XAML และใช้คุณสมบัติ WPF ทั้งหมดคุณสมบัติเหล่านั้นจะต้องมีคุณสมบัติการพึ่งพา

อย่างไรก็ตาม ViewModel ของคุณดีกว่าการใช้ INotifyPropertyChanged การใช้ INotifyPropertyChanged จะทำให้คุณมีความสามารถในการมี getter / setter logic หากคุณต้องการ

ฉันขอแนะนำให้ตรวจสอบรุ่นพื้นฐานของ Josh Smith สำหรับ ViewModel ที่ใช้ INotifyPropertyChanged แล้ว:

http://joshsmithonwpf.wordpress.com/2007/08/29/a-base-class-which-implements-inotifypropertychanged/

ฉันคิดว่านี่เป็นตัวอย่างที่ยอดเยี่ยมของวิธีการทำ ViewModel

ฉันคิดว่า DependencyProperty และ INotifyPropertyChanged ใช้สำหรับสองสิ่งใน Binding: สิ่งแรกที่ทำให้คุณสมบัติเป็นเป้าหมายของการเชื่อมโยงและรับอินพุตจากคุณสมบัติอื่น (ใช้ {Binding ... } เพื่อตั้งค่าคุณสมบัติ) สุดท้าย เมื่อคุณต้องการให้ค่าของคุณสมบัติถูกใช้เป็นแหล่งที่มาของการรวม (ชื่อใน Binding Path Expression) ดังนั้นทางเลือกจึงเป็นเพียงทางเทคนิค

ฉันชอบวิธีการโดยตรงมากขึ้นซึ่งผม blogged เกี่ยวกับในการนำเสนอรูปแบบโดยไม่ต้อง INotifyPropertyChanged คุณสามารถผูกกับคุณสมบัติ CLR ได้โดยตรงโดยไม่ต้องใช้รหัสอื่นใด ๆ คุณเพิ่งเขียนรหัส. NET แบบธรรมดาใน View Model ของคุณและมันจะได้รับการอัพเดทเมื่อ Data Model ของคุณเปลี่ยนไป

มีเพียงสิ่งเดียวที่ต้องเลือกDependencyObject- การผูกจะทำงานได้ดีขึ้น เพียงลองตัวอย่างด้วยListBoxและTextBoxเติมรายการที่มีข้อมูลจากINotifyPropertyChangedคุณสมบัติเทียบกับDependencyPropertyและแก้ไขรายการปัจจุบันจากTextBox...

หากคุณต้องการแสดงคุณสมบัติให้กับตัวควบคุมอื่นคุณต้องใช้คุณสมบัติการพึ่งพา ... แต่โชคดีเพราะพวกเขาใช้เวลาสักครู่ในการคิดออก ...