فقط یه نکته هنوز برام مشخص نشده که تو کدوم قسمت وهله ای به @Model پاس داده میشه...
تا اونجایی که من متوجه شدم توی فضای نام Models دو تا کلاس Product و Products وجود داره و اینکه @Model وهله ای از لیست محصولات(که همون Products هست) به حساب میاد، درسته؟ پس فکر کنم مشکل من بر میگرده به اینکه با ساختار List<T>class آشنایی ندارم ، به این خاطره یا چیز دیگس؟

در ادامه‌ی بخش اول از سری انقیاد داده‌ها در WPF، نحوه‌ی انقیاد داده‌ها در لیست را بررسی می‌کنیم.

• One Way Binding بخش اول

• INPC  بخش اول

• Tow Way Binding بخش اول

• List Binding  بخش دوم

• Element Binding بخش دوم

• Data Conversion بخش دوم

انقیاد در لیست List Binding

در ابتدا متدی با نام GetEmployees را با ساختار زیر، به کلاس Employee ایجاد شده‌ی در بخش اول این سری آموزشی، اضافه می‌کنیم: 

در کد بالا از نوع داده‌ی جنریک ObservableCollection برای برگردان لیست کارمندان استفاده کردیم.

توجه : ObservableCollection در فضای نام System.Collections.ObjectModel قرار دارد.

ObservableCollection  چیست؟

یک مجموعه‌ی پویا (Dynamic Collection) است که بر اثر عملیات‌هایی همچون به‌روز رسانی، حذف و ایجاد اشیاء در آن، یک اعلان صادر می‌شود و View از این اعلان مطلع می‌شود؛ شبیه به کاری که INotifyPropertyChanged انجام می‌دهد. 

در اینجا کلاس Employee با پیاده سازی اینترفیس INPC (معرفی شده در قسمت قبل) به یک کلاس Observable تبدیل شده است. بدین معنی که هر تغییری در وضعیت خصوصیات خود را اعلان می‌کند. با قرار دادن این شیء Observable در یک مجموعه که خود نیز از نوع Observable می‌باشد، از این پس هر تغییری در مجموعه نیز مستقیما View ما را تحت تاثیر قرار می‌دهد.

برای درک بهتر این موضوع در بخش markup، یک Combobox را قرار می‌دهیم:

<ComboBox Name="President" ItemsSource="{Binding}" FontSize="30"
                  Height="50"
                  Width="550">
            <ComboBox.ItemTemplate>
                <DataTemplate>
                    <StackPanel Orientation="Horizontal">
                        <TextBlock Text="{Binding Name}"/>
                        <TextBlock Text="{Binding Title}" Margin="5,0,0,0"/>
                    </StackPanel>
                </DataTemplate>
            </ComboBox.ItemTemplate>
 </ComboBox>

• در Tag مربوط به تعریف Combobox از طریق خصوصیت ItemSource اعلام کردیم که عملیات DataBinding اتفاق خواهد افتاد. پس Combobox ما به منبع داده‌ی پیش فرض در WPF که همان DataContext است مرتبط می‌شود. برای پر کردن منبع داده نیز همانند بخش قبل از طریق سازنده اقدام می‌کنیم.

• برای نمایش عناصر در ComboBox، کار کمی متفاوت‌تر از عملیات انقیاد در یک TextBlock است. در کنترل‌هایی که قرار است لیستی از داده‌ها را پس از عملیات انقیاد نمایش دهند، می‌بایستی قالب نمایش داده‌ها مشخص شود.

حال باید نحوه‌ی نمایش و اعضایی از مجموعه که قرار است، در کنترل به نمایش در آیند مشخص شوند. در اینجا از Combobox.ItemTemplate برای مشخص کردن قالب و همچنین از DataTemplate، برای مشخص کردن داده‌های منتخب ما از مجموعه، استفاده شده است.

بعد از اجرای برنامه اطلاعات نام و عنوان، در Combobox نمایش داده می‌شوند. برای تست ویژگی Observable بودن مجموعه هم کافی است یک دکمه را بر روی صفحه قرار دهید و یک آیتم جدید را به لیست employees واقع در بخش CodeBehind اضافه کنید. مشاهده خواهید کرد که View ما با تغییر منبع داده، بطور اتوماتیک به‌روز می‌شود.

 انقیاد عناصر Element Binding 

در این بخش قصد داریم از یک کنترل به‌عنوان منبع داده استفاده کنیم. کنترل منتخب ما در این مثال یک Slider می‌باشد. در بخش markup کد زیر را اضافه می‌کنیم:

Value خصوصیتی است که مقدار Slider را برمی گرداند. پس از اجرای برنامه و حرکت ولوم اسلایدر مشاهده می‌کنید که مقدار جاری اسلایدر در textblock نمایش داده می‌شود.

Data Conversion 

برای درک بهتر مفهوم تبدیل داده در Data Binding با یک مثال کار را شروع می‌کنیم. به کلاس Employee موجود در بخش قبل، یک خصوصیت جدید را به نام تاریخ تولد، اضافه می‌کنیم:

و متدی که لیستی از پرسنل را برای ما تولید می‌کرد، به شکل زیر بازنویسی می‌کنیم:

حال قصد داریم اطلاعات را در یک ListBox، در بخش Markup نمایش دهیم:

 همانطور که قبلا اشاره شد، در نمایش لیست‌ها باید قالب و داده‌های مورد نظر برای نمایش، مشخص شوند.

پس از اجرا، خروجی برنامه به شکل زیر است:

 

 همه چیز همانطور که انتظار داشتیم به نمایش درآمد؛ اما اگر بخواهیم تاریخ میلادی، در زمان نمایش در View، بصورت شمسی نمایش داده شود، چطور؟

عملیات تبدیل داده یا همان Data Conversion در اینجا به کمک ما می‌آید.

به شکل زیر دقت کنید:

در زمانیکه در عملیات Data Binding نوع داده‌ی خصوصیت ما در Source (منبع داده) با نوع داده‌ی خصوصیت ما در target  (کنترل یا View) متفاوت است، به یک مبدل در حین Binding نیاز داریم. این کار را از طریق یک کلاس که اینترفیس IValueConvertor را پیاده سازی کرده است، انجام می‌دهیم.

در مثال ذکر شده می‌خواهیم تاریخ میلادی موجود در منبع داده را به یک رشته (تاریخ شمسی) تبدیل کنیم و در View نمایش دهیم. (تبدیل نوع داده‌ی میلادی به رشته)

کلاسی را با نام DateConverter ایجاد می‌کنیم و اینترفیس IValueConverter را به شکل زیر پیاده سازی می‌کنیم:

اینترفیس IValueConverter دو متد دارد:

• Convert جهت تبدیل اطلاعات از مبداء به مقصد 

• ConvertBack برای تبدیل اطلاعات از مقصد به مبداء

در متد Convert همانطور که می‌بینید مقدار تاریخ میلادی ارسال شده، به یک رشته تبدیل شده و بازگردانده می‌شود.

حال برای استفاده از این مبدل باید مراحل زیر انجام شود: 

• اضافه کردن فضای نام مبدل به بخش فضاهای نام در View؛ که در اینجا همان آدرس پروژه‌ی جاری است:

• ایجاد یک شیء از مبدل و اضافه کردن آن به بخش Resource‌ها در view جاری:

markup مربوط به Resource یک پارامتر می‌گیرد و آن هم Key  است. Key کلید آیتم موجود در دیکشنری Resource است. اینجا کلید را MyConverter تعریف کردیم تا در بخش بعدی به‌راحتی بتوانیم از طریق آن اطلاعات را از Resource بازیابی کنیم.

• ارجاع به Static Resource که در مرحله‌ی قبل مقدار دهی کردیم:

پس از طی مراحل بالا، برنامه را مجددا اجرا کنید. اینبار خروجی به شکل زیر است:

در مورد طراحی یک برنامه "فرم ساز" در مطلب قبلی بحث شد ... حدودا سه سال قبل اینکار را برای شرکتی انجام دادم. یک برنامه درخواست خدمات نوشته شده با ASP.NET که مدیران برنامه می‌توانستند برای آن فرم طراحی کنند؛ فرم درخواست پرینت، درخواست نصب نرم افزار، درخواست وام، درخواست پیک، درخواست آژانس و ... فرم‌هایی که تمامی نداشتند! آن زمان برای حل این مساله از فیلدهای XML استفاده کردم.
فیلدهای XML قابلیت نه چندان جدیدی هستند که از SQL Server 2005 به بعد اضافه شده‌اند. مهم‌ترین مزیت آن‌ها‌ هم امکان ذخیره سازی اطلاعات هر نوع شیء‌ایی به عنوان یک فیلد XML است. یعنی همان زیرساختی که برای ایجاد یک برنامه فرم ساز نیاز است. ذخیره سازی آن هم آداب خاصی را طلب نمی‌کند. به ازای هر فیلد مورد نظر کاربر، یک نود جدید به صورت رشته معمولی باید اضافه شود و نهایتا رشته تولیدی باید ذخیره گردد. از دید ما یک رشته‌ است، از دید SQL Server یک نوع XML واقعی؛ به همراه این مزیت مهم که به سادگی می‌توان با T-SQL/XQuery/XPath از جزئیات اطلاعات این نوع فیلدها کوئری گرفت و سرعت کار هم واقعا بالا است؛ به علاوه بر خلاف مطلب قبلی در مورد dynamic components ، اینبار نیازی نیست تا به ازای هر یک فیلد درخواستی کاربر، واقعا یک فیلد جدید را به جدول خاصی اضافه کرد. داخل این فیلد XML هر نوع ساختار دلخواهی را می‌توان ذخیره کرد. به عبارتی به کمک فیلدهایی از نوع XML می‌توان داخل یک سیستم بانک اطلاعاتی رابطه‌ای، schema-less کار کرد (un-typed XML) و همچنین از این اطلاعات ویژه، کوئری‌های پیچیده هم گرفت.
تا جایی که اطلاع دارم، چند شرکت دیگر هم در ایران دقیقا از همین ایده فیلدهای XML برای ساخت برنامه فرم ساز استفاده کرده‌اند ...؛ البته مطلب جدیدی هم نیست؛ برنامه‌های فرم ساز اوراکل و IBM هم سال‌ها است که از XML برای همین منظور استفاده می‌کنند. مایکروسافت هم به همین دلیل (شاید بتوان گفت مهم‌ترین دلیل وجودی فیلدهای XML در SQL Server)، پشتیبانی توکاری از XML به عمل آورده‌ است.
یا روش دیگری را که برای طراحی سیستم‌های فرم ساز پیشنهاد می‌کنند استفاده از بانک‌های اطلاعاتی مبتنی بر key-value‌ مانند Redis یا RavenDb است؛ یا استفاده از بانک‌های اطلاعاتی schema-less واقعی مانند CouchDb.


خوب ... اکنون سؤال این است که NHibernate برای کار با فیلدهای XML چه تمهیداتی را درنظر گرفته است؟
برای این منظور خاصیتی را که قرار است به یک فیلد از نوع XML نگاشت شود، با نوع XDocument مشخص خواهیم ساخت:

سپس باید جهت معرفی این نوع ویژه، به صورت صریح از XDocType استفاده کرد؛ یعنی نکته‌ی اصلی، استفاده از CustomType مرتبط است:

البته لازم به ذکر است که دو نوع NHibernate.Type.XDocType و NHibernate.Type.XmlDocType برای کار با فیلد‌های XML در NHibernate وجود دارند. XDocType برای کار با نوع System.Xml.Linq.XDocument طراحی شده است و XmlDocType مخصوص نگاشت نوع System.Xml.XmlDocument است.

اکنون اگر به کمک کلاس SchemaExport ، اسکریپت تولید جدول متناظر با اطلاعات فوق را ایجاد کنیم به حاصل زیر خواهیم رسید:

یک سری اعمال متداول ذخیره سازی اطلاعات و تهیه کوئری نیز در ادامه ذکر شده‌اند:

و در پایان بدیهی است که جهت کار با امکانات پیشرفته‌تر موجود در SQL Server در مورد فیلد‌های XML ( برای نمونه: + و +) باید مثلا رویه ذخیره شده تهیه کرد (یا مستقیما از متد CreateSQLQuery همانند مثال فوق کمک گرفت) و آن‌را در NHibernate مورد استفاده قرار داد. البته به این صورت کار شما محدود به SQL Server خواهد شد و باید در نظر داشت که در کل تعداد کمی بانک اطلاعاتی وجود دارند که نوع‌های XML را به صورت توکار پشتیبانی می‌کنند.

<Child :childCounter="parentCounter"/>

<template>
  <div>
    <div>
      <h2>Parent Component</h2>
      <!-- را نمایش میدهید parentCounter مقدار -->
      <h1>{{ parentCounter }}</h1>
      <button @click="increase">Increase Parent</button>
    </div>
    <div>
      <!-- پاس میدهید Child در کامپوننت childCounter را به پراپرتی parentCounter مقدار -->
      <!--از طریق  decreaseParent سبب اتصال و فراخوانی تابع  @callDecreaseParent به  decreaseParent با انتساب -->
      <!-- میشود Child  در کامپوننت  callDecreaseMethodInParent تابع   -->
      <Child :childCounter="parentCounter" @callDecreaseParent="decreaseParent"/>
    </div>
  </div>
</template>

<script>
//برای استفاده در کامپوننت جاری Child ایمپورت کردن کامپوننت
import Child from "./Child.vue";

export default {
  // در این بخش متغیرهای مورد نیاز کامپوننت را تعریف میکنیم
  data() {
    return {
      parentCounter: 0
    };
  },
  components: {
    // میتوان آرایه ای از کامپوننت‌ها را در یک کامپوننت استفاده نمود
    // در این مثال فقط از یک کامپوننت استفاده شده
    Child
  },
  methods: {
    //را یک واحد افزایش میدهد parentCounter این متد مقدار
    increase() {
      this.parentCounter++;
    },
    decreaseParent() {
      this.parentCounter--;
    }
  }
};
</script>

<style>
.parent-block,
.child {
  text-align: center;
  margin: 20px;
  padding: 20px;
  border: 2px gray solid;
}
</style>

<template>
  <div>
    <h3>Child Component</h3>
    <!-- را نمایش میدهید childCounter مقدار -->
    <h3>{{ childCounter }}</h3>
    <button @click="increase">Increase Me</button>
    <button @click="callDecreaseMethodInParent">Call Decrease Method In Parent</button>
  </div>
</template>

<script>
export default {
  // استفاده میشود Child به  Parent برای ارتباط بین کامپوننت  props از
  props: {
    childCounter: Number
  },
  data() {
    return {};
  },
  methods: {
    //را یک واحد افزایش میدهد childCounter این متد مقدار
    increase() {
      this.childCounter++;
    },
    // فراخوانی میکند Parent را در کامپوننت decreaseParent تابع
    callDecreaseMethodInParent() {
      this.$emit("callDecreaseParent");
    }
  }
};
</script>

<template>
  <div id="app">
    <img alt="Vue logo" src="./assets/logo.png">
    <parent></parent>
  </div>
</template>

<script>
import Parent from "./components/Parent.vue";

export default {
  name: "app",
  components: {
    parent: Parent
  }
};
</script>
<style>
#app {
  width: 50%;
  margin: 0 auto;
  text-align: center;
}
</style>

npm run serve

 this.$emit("callDecreaseParent");

      <Child  @callDecreaseParent="decreaseParent"/>

npm install

this.$emit 
//dispatches an event to its parent component

this.$parent
// gives you a reference to the parent component

this.$root
// gives you a reference to the root component

this.$parent.$emit
// will make the parent dispatch the event to its parent

this.$root.$emit
// will make the root dispatch the event to itself

npm install

npm install node-sass

1 - به کامنت بالایی مراجعه کنید و ساختار DropDownList  رو مطالعه کنید. همان طور که می‌بینید مقداری که به سرور ارسال می‌شود همان مقدار داخل Value است.

این شما هستید که DropDown رو می‌سازید، همان مقداری که در value  قرار می‌دهید ارسال می‌شود.

2 -  برای این هم شما رو ارجاع می‌دم به ساختار Radio button .

نمونه:

شما در این جا دو radio  دارید که دارای نام یکسال هستند و مقادیر Value  آن‌ها تفاوت دارد.

در اینجا هم شما می‌توانید در کنترلر خود با name  ان radio  مقدار آن را در یافت کنید.

به عنوان مثال شما در کنترلر یکی از مقدار‌های male و  female  را دریافت می‌کنید.

CREATE TABLE T (nbr INT NOT NULL);
INSERT T VALUES (1), (2), (3), (4), (5), (6), 
                (7), (8), (9), (10), (11), (12);

SELECT nbr, ntl, NTILE(3) OVER(PARTITION BY ntl ORDER BY nbr) AS grp
FROM (
         SELECT nbr, NTILE(2) OVER(ORDER BY nbr) ntl
         FROM T
     ) AS D;

SELECT nbr, rnk1, rnk2,
       (rnk1 + 1) / 2 AS grp2,
       (rnk1 - 1) / 2 + 1 AS grp2
FROM
(
SELECT nbr, 
       ROW_NUMBER() OVER(PARTITION BY (nbr + 5) / 6 ORDER BY nbr) rnk1,
       (nbr - 1) % 6 + 1 AS rnk2
FROM t
)d

Here are some of the reasons why nullable reference types are less than ideal:

• Invoking a member on a null value will issue a System.NullReferenceException exception, and every invocation that results in a System.NullReferenceException in production code is a bug. Unfortunately, however, with nullable reference types we “fall in” to doing the wrong thing rather than the right thing. The “fall in” action is to invoke a reference type without checking for null.
• There’s an inconsistency between reference types and value types (following the introduction of Nullable<T>) in that value types are nullable when decorated with  “?” (for example, int? number); otherwise, they default to non-nullable. In contrast, reference types are nullable by default. This is “normal” to those of us who have been programming in C# for a long time, but if we could do it all over, we’d want the default for reference types to be non-nullable and the addition of a “?” to be an explicit way to allow nulls.
• It’s not possible to run static flow analysis to check all paths regarding whether a value will be null before dereferencing it, or not. Consider, for example, if there were unmanaged code invocations, multi-threading, or null assignment/­replacement based on runtime conditions. (Not to mention whether analysis would include checking of all library APIs that are invoked.)
• There’s no reasonable syntax to indicate that a reference type value of null is invalid for a particular declaration.
• There’s no way to decorate parameters to not allow null. 

الگوی Service Locator، به صورت گسترده‌ای به عنوان یک ضد الگو شناخته می‌شود و هنگامیکه از این الگو استفاده می‌کنیم ما را با یک سری از مشکلات رو به رو می‌کند. ولی این الگوی طراحی به خودی خود منشاء مشکل نیست. مشکل اصلی این الگو نحوه استفاده از آن است که در این مقاله درباره آن بحث می‌کنیم.