مزیت استفاده از خصوصیت [MessageContract]

[Jean Reno]

با سلام
همان طور که می دانیم با قرار دادن خصوصیت [MessageContract] در ابتدای یک کلاس تعریف شده در سمت سرویس دهنده می توان به ازای هر کدام از متغیرهای موجود دراین کلاس محل قرارگیری آن ها را در پیام های رد و بدل شده بین میزبان وسرویس دهنده تعیین نمود به و به نوعی محل قرار گیری متغیر کلاس را که در قسمت Message Body قرار گیرد یا در Message Header تعیین نمود

حال سوال بنده این است که این کار چه مزیتی را برای ما فراهم می سازد ؟ آیا بر امنیت اطلاعات رد و بدل شده تاثیری خواهد گذاشت ؟
و یا بر نحوه دسترسی به کلاس و مقادیر در سمت میزبان ها ؟
آیا با تعریف خصوصیت [MessageContract] دیگر نیازی به تعریف خصوصیت [DataContract] نیست ؟

نحوه تعریف یک کلاس و اعمال خصوصیت [MessageContract] :



[MessageContract]
public class TradeSecurityRequest
{
Trade _trade;
string _particpant;
string _publisher;
string _ticker;
[MessageHeader(MustUnderstand=true)]
public string Participant
{
get
{
return _particpant;
}
set
{
_particpant = value;
}
}
[MessageBody]
public Trade TradeItem
{
get
{
return _trade;
}
set
{
_trade = value;
}
}

[Jean Reno]

پس از جستجو تو مقالات و منابع مختلف بالاخره به نتیجه نسبی رسیدم
نتیجه این جستجو ها رو در قالب یک مقاله کوتاه مختصر در این قسمت قرار دادم تا مورد استفاده دیگر دوستان نیز قرار بگیره

همان طور که می دانیم برای ایجاد نوع داده های جدید سمت سرور از کلاس ها استفاده میکنیم و یک شی از کلاس را ایجاد و پس از مقدار دهی پارامترها به سمت کلاینت ارسال می کنیم .

برای این که این کلاس تعریف شده سمت سرور ، در طرف کلاینت قابل شناسایی و مشاهده باشد بایستی قبل از این کلاس از خصوصیت های خاص WCF استفاده کنیم
در کل سه خصوصیت را می توان در این مورد به کار برد :


Data Contracts
Message Contracts
XML serialization


همان طور که می دانیم پیام ها بین سرور و کلاینت بصورت XML رد و بدل می شوند حال اگر خود داده ما که قرار است به سمت کلاینت ارسال شود از نوع XML باشد چه ؟ اگر محتوای این داده حاوی تگ های رزرو شده و تعریف شده در متن پیام ارسالی باشد چه ؟

در صورتی که متن داده ارسالی ما از نوع XML باشد بایستی کلاس تعریف شده جهت نگاه داری این مقادیر و ارسال به سمت کلاینت با خصوصیت XML serialization مشخص گردد تا محتوای داده XML ای ما موجب مخدوش شدن قالب پیام ارسالی که آن هم در قالب XML است نشود و سریالایز و دی سریالایز این نوع کلاس ها به گونه دیگری صورت می گیرد .

اما برای تعریف کلاس های با انواع داده ای دیگر می توان از هر دو خصوصیت data contracts و message contracts استفاده کرد . هر چند استفاده از خصوصیت data contracts رایج تر و مرسوم تر است . معمولا زمانی از خصوصیت message contracts در تعریف کلاس ها استفاده میشود که زمانی که یک شی از کلاسی مقداردهی می شود و به سمت کلاینت ارسال می گردد نیاز باشد که محل قرار گیری پارامترهای موجود در کلاس در بخش متن پیام ارسالی که از جنس XML است مشخص گردد .

به عنوان مثال در صورت نیاز می توان یکی از پارامترهای موجود در کلاس را در Message Header قرار داد و پارامتر دیگر را در بخش Message Body . حال این چه مزیتی را برای ما ایجاد می کند و یا چه زمانی مجبور به استفاده از این حالت هستیم هنوز مشخص نیست ؟

اما معمولا تمام منابع بر این موضوع که استفاده از Data Contract به جای Message Contract بهتر است تاکید داشتند و همواره Data Contract بر Message Contract ترجیح داده می شد . شاید به دلیل پارامترهایی که هنگام تعریف Data Contract می توان اعمال نمود .

تعریف DataContract




[DataContract]
public class ProductClass
{
[DataMember]
public int ProductID{ get; set; }

[DataMember]
public string ProductName { get; set; }
}




تعریف MessageContract





[MessageContract]
public class CustomerClass
{
[MessageHeader]
public int CustomerID { get; set; }

[MessageBodyMember]
public string CustomerName { get; set; }
}

[sia_2007]

از تلاشت خوشم اومد؛

Understanding Protection Level (http://msdn.microsoft.com/en-us/library/aa347692.aspx?appId=Dev10IDEF1&l=EN-US&k=k%28SYSTEM.SERVICEMODEL.MESSAGECONTRACTATTRIBUTE .PROTECTIONLEVEL%29;k%28TargetFrameworkMoniker-%22.NETFRAMEWORK&k=VERSION=V4.0%22%29;k%28DevLang-CSHARP%29&rd=true)

تو خود مقاله هم نوشته؛ و البته بدیهی هم هست و حتما خودت هم میدونی که وقتی Transport Message Security رو اعمال میکنی؛ دیگه این امر بی معنیه.
اما خب؛ داشتن Message Security برای یک Message Contract خاص؛ یا حتی یک فیلد خاص؛ خیلی خیلی بهتر از Transport Security هستش؛ چون سربارش برای سیستم خیلی کمتره
در ضمن میشه فارغ از Security ؛ Integrity خود Message Contract یا تک تک فیلدها رو تضمین کرد.
این جدا از اون تضمین Channel های Reliable هستش؛ مثل netTcpBinding
در ضمن وقتی چیزی رو تو Header قرار میدی؛ زمانی که داری یه Message Inspector مینویسی؛ میتونی چیزی که تو Name اون Header قرار میدی رو Fetch کنی؛ مثلا میخوای یک سری Message های خاص رو Log کنی تو دیتابیس؛ برای این کار؛ میآی مثلا میذاری "For Log" و بعد؛ Message ها رو Inspect میکنی و اونهایی رو که این مقدار رو دارن رو log میکنی
http://barnamenevis.org/forum/attachment.php?attachmentid=57040&stc=1&d=1285390855
البته من این استفاده دوم رو تایید نمیکنم؛ ولی مطمئنم اگه روش فکر بشه ؛ میشه چیزهای خوبی ازش در بیاد.
موفق باشی