डब्ल्यूसीएफ

Question

का उपयोग कर आवेदन संरचना मेरे पास एक WPF एप्लिकेशन है जो अब तक केवल क्लाइंट रहा है, लेकिन अब मैं इसे क्लाइंट और सर्वर पक्ष में विभाजित करने पर काम कर रहा हूं। इस काम में मैं क्लाइंट-सर्वर संचार के लिए डब्ल्यूसीएफ पेश कर रहा हूं। मेरे आवेदन में कई परियोजनाएं हैं, और इनमें से एक से अधिक से सेवा संदर्भों की आवश्यकता है।

जुदाई करने में प्रारंभिक प्रयास सब कुछ करने के लिए "सीधे आगे है।" किसी सेवा के साथ संवाद करने की आवश्यकता वाली सभी परियोजनाओं को एक सेवा संदर्भ मिलता है, और इसलिए मुख्य WPF एप्लिकेशन प्रोजेक्ट करें - वहां app.config प्राप्त करने के लिए। मुझे यह एक गड़बड़ में तेजी से बदलने के लिए लगता है, और मैं कल्पना नहीं कर सकता कि यह सामान्य वास्तुकला का उपयोग करने वाले लोग हैं? मैंने इस तथ्य के साथ समस्याएं भी देखी हैं कि प्रत्येक सेवा संदर्भ डेटाकंट्रैक्ट कक्षाओं का एक नया कार्यान्वयन उत्पन्न करता है - इसलिए परियोजनाओं के पार पर डेटाकंट्रैक्ट कक्षाओं की कोई सामान्य समझ नहीं है। मेरे पास एक प्रोजेक्ट में कुछ व्यूमोडेल क्लासेस हैं, और एक अन्य प्रोजेक्ट कुछ व्यूमोडेल को कम करता है। मैं सेवा से प्राप्त ऑब्जेक्ट को पास करना चाहता हूं, लेकिन मैं नहीं कर सकता क्योंकि ऑब्जेक्ट के जेनरेट क्लाइंट-साइड का प्रतिनिधित्व प्रत्येक प्रोजेक्ट में अलग है।

तो - वहाँ WCF का उपयोग कर संरचना इस तरह के ग्राहक/सर्वर विभाजन की सिफारिश की तरीका है? या सिद्धांतों का पालन करने के लिए? मैं क्लाइंट पक्ष पर उपयोग की जाने वाली एक आम प्रॉक्सी प्रोजेक्ट सोच रहा हूं जो सेवाओं के साथ संचार करता है, प्राप्त डेटा को लपेटता है, और क्लाइंट पुस्तकालयों के लिए अच्छी तरह से ज्ञात रूप में डेटा लौटाता है। केवल एक सेवा संदर्भ देना चाहिए, और मुझे लगता है कि मुझे केवल wpfApp-project में App.config की आवश्यकता है? इसका कोई मतलब भी है क्या?

Answer 1

मैं इस तरह मेरी WCF समाधान की संरचना के:

संविदा (वर्ग पुस्तकालय)
सभी सेवा, संचालन, गलती, और डेटा ठेके शामिल हैं।एक शुद्ध नेट-टू-नेट परिदृश्य में सर्वर और ग्राहक के बीच साझा किया जा सकता है

सेवा कार्यान्वयन (वर्ग पुस्तकालय)
सेवाओं को लागू करने के कोड शामिल होता है, और किसी भी समर्थन/सहायक तरीकों इस लक्ष्य को हासिल करने के लिए आवश्यक । और कुछ नहीं।

सेवा मेजबान (रों) (वैकल्पिक - Winforms, कंसोल अनुप्रयोग, NT सेवा हो सकता है)
डिबगिंग/परीक्षण के लिए सेवा मेजबान (रों), या संभवतः भी उत्पादन के लिए होता है।

यह मूल रूप से मुझे चीजों का सर्वर-पक्ष देता है।

ग्राहक के पक्ष में:

क्लाइंट प्रॉक्सी (वर्ग पुस्तकालय)
मैं एक अलग वर्ग पुस्तकालय में मेरे मुवक्किल प्रॉक्सी पैकेज है, ताकि वे एक से अधिक वास्तविक ग्राहक एप्लिकेशन द्वारा उपयोग किया जा सकता की तरह। यह svcutil या "सेवा संदर्भ जोड़ें" का उपयोग करके और परिणामस्वरूप भयानक app.config के मैन्युअल रूप से tweaking कर सकते हैं, या ClientBase<T> या ChannelFactory<T> संरचनाओं का उपयोग कर क्लाइंट प्रॉक्सी के मैन्युअल कार्यान्वयन (अनुबंध अनुबंध को साझा करते समय) मैन्युअल रूप से tweaking कर सकते हैं।

1-एन वास्तविक ग्राहकों (अनुप्रयोग के किसी भी प्रकार के)
आम तौर पर केवल ग्राहक प्रॉक्सी विधानसभा का संदर्भ होगा, या हो सकता है अनुबंध विधानसभा, भी, अगर यह साझा किया जा रहा। यह एएसपी.नेट, डब्ल्यूपीएफ, विनफॉर्म, कंसोल ऐप, अन्य सेवाएं हो सकता है - आप इसे नाम दें।

इस तरह से; मेरे पास एक अच्छा और साफ लेआउट है, मैं लगातार बार-बार इसका उपयोग करता हूं, और मुझे सच में लगता है कि इसने मेरे कोड क्लीनर को बनाए रखा है और इसे बनाए रखना आसान है।

यह कार्ल फ्रैंकलिन के साथ डॉटनेट रॉक्स टीवी पर मिगुएल कास्त्रो के Extreme WCF screen cast से प्रेरित था - अत्यधिक अनुशंसित स्क्रीन कास्ट!

Answer 2

यह निर्भर करता है। डब्ल्यूसीएफ एक बड़ा ढांचा है और इसका मतलब कई अलग-अलग परिदृश्यों में फैलाना है।

सभी DataContract वर्गों और ServiceContract इंटरफेस एक पुस्तकालय में जाने (:

लेकिन आपके जैसे एक सीधा आवेदन, जब आप जावा इंटरॉप या सामान्य वेब सेवाओं इंटरॉप की तरह सामान के बारे में परवाह नहीं है के लिए, यह है कि मुझे क्या करना है या पुस्तकालय) जो क्लाइंट और सर्वर के बीच साझा किया जाता है। ध्यान दें कि आपको शायद सेवा कंट्रैक्ट के साथ अपनी सेवा कार्यान्वयन को सजाने नहीं चाहिए, आप सर्विसकंट्रैक्ट विशेषताओं के साथ एक अलग इंटरफ़ेस बनाएंगे जिसे आप साझा असेंबली में डाल सकते हैं।

तो तुम सही प्रत्येक भाग को के बारे में बस कर कर रहे हैं। आपको इस मामले में प्रॉक्सी को स्वचालित रूप से उत्पन्न करने की आवश्यकता नहीं है। यह सिर्फ आपको दर्द का कारण बन रहा है। तो आप जो भी कर रहे हैं उसके लिए सेवा जोड़ें संदर्भ संवाद का उपयोग न करें। साझा लाइब्रेरी में परिभाषित आपके सेवा इंटरफ़ेस में प्रॉक्सी प्राप्त करने के लिए बस अपनी साझा डेटा कंट्रैक्ट असेंबली शामिल करें और चैनलफ़ैक्टरी का उपयोग करें। यह आपको विजुअल स्टूडियो में प्रॉक्सी को फिर से उत्पन्न करने से रोकता है, जो किसी भी सभ्य आकार के प्रोजेक्ट के लिए पुराना हो जाता है।

आप इस मार्ग जा रहे हैं, तो आप भी MetaDataExchange endpoint से छुटकारा मिल सकता है, क्योंकि यह है कि केवल ग्राहक के लिए सेवा का वर्णन करने के लिए आवश्यक है। चूंकि आप किसी साझा असेंबली में सबकुछ करते हैं, इसलिए आपको सेवा विवरण की आवश्यकता नहीं है, क्योंकि आपके पास कोड फ़ॉर्म में पहले से ही सेवा विवरण है।

Answer 3

सामान्य संरचना मैं का उपयोग करें:

आम - इंटरफेस, डेटा-अनुबंध, सेवा अनुबंध, सार कक्षाएं आदि शामिल हैं; ग्राहक - संदर्भ सामान्य, सर्वर प्रॉक्सी कक्षा शामिल है; सर्वर - संदर्भ सामान्य, वास्तविक कार्यान्वयन वर्ग शामिल हैं;