डब्ल्यूसीएफ/क्लाइंट ऐप्स - व्यवसाय तर्क कहां जाना चाहिए?

Question

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

अब प्रश्न यह है कि व्यापार तर्क (डेटा का उपयोग करने वाले) को कहां स्थित किया जाना चाहिए? मैंने सोचा कि मैं इसे सेवा के अंदर रखूंगा। मेरे पास पहले से ही साधारण ऑब्जेक्ट्स के साथ एक व्यावसायिक परत है जो डाटाबेस (ग्राहक, ऑर्डर इत्यादि) के साथ लगभग एक से एक को मैप करती है। मुझे लगा कि मैं डेटा में हेरफेर करने के लिए कुछ "उच्च स्तर" ऑब्जेक्ट्स बनाउंगा। उदाहरण के लिए ग्राहक, ऑर्डर और अन्य ऑब्जेक्ट्स का उपयोग करके और एक रिपोर्ट तैयार करना आदि। मैंने सोचा कि इसके लिए सबसे अच्छी जगह सेवा के लिए व्यावसायिक परत में होगी। इस तरह यदि आवश्यक हो तो हम इस तर्क को विभिन्न विभिन्न अनुप्रयोगों के लिए पुन: उपयोग कर सकते हैं।

दुर्भाग्य से मेरा मालिक सहमत नहीं है। वह "चिंताओं को अलग करना" चाहता है और कहा कि इस तर्क के लिए सही जगह ग्राहक सेवा के बजाय ग्राहक ऐप के अंदर एक व्यावसायिक परत में होगी। मुझे लगता है कि यह आसान हो सकता है लेकिन मैं इस कोड को लिखने के लिए सेवा व्यवसाय परत के अंदर अपने शक्तिशाली ऑब्जेक्ट मॉडल का उपयोग करना चाहता हूं। सेवा द्वारा उजागर की गई वस्तुएं "वास्तविक" वस्तुएं नहीं हैं और सेवा व्यवसाय परत के अंदर मौजूद पूर्ण ऑब्जेक्ट मॉडल की शक्ति के बिना वास्तव में केवल हल्के वजन डेटा संरचनाएं हैं।

आप क्या सोचते हैं? सहायता के लिए बहुत - बहुत धन्यवाद।

चीयर्स मार्क

Answer 1

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

आप अभी भी चिंताओं को अलग कर सकते हैं कि क्लाइंट या सर्वर पर व्यवसाय तर्क लागू किया गया है या नहीं। यह वह जगह नहीं है जहां आप प्रसंस्करण करते हैं, लेकिन आवेदन के स्तरों के बीच इंटरफेस को आपने कितनी साफ तरीके से डिजाइन किया है।

यह ग्राहक के बारे में अधिक जानने में मदद कर सकता है। क्या आप ब्राउज़र/जावास्क्रिप्ट क्लाइंट से काम कर रहे हैं? यदि ऐसा है तो मैं सर्वर पर जितना संभव हो उतना प्रसंस्करण रखूंगा और उस फ़ॉर्म में क्लाइंट को डेटा कम से कम भेज दूंगा जिसे आप प्रदर्शित करना चाहते हैं।

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

Answer 2

इसके लिए कोई कठोर और तेज़ नियम नहीं है, लेकिन इस मामले में मैं कहूंगा कि आपका मालिक आपके से अधिक गलत है :) हर किसी के पास थोड़ा अलग होगा इस पर राय, और व्यावसायिक कारणों के अलावा अन्य जगहों पर आपका व्यावसायिक तर्क क्यों रखा जा सकता है, लेकिन क्लाइंट ऐप में इसे रखने का कोई कारण नहीं है - आप तर्क दे सकते हैं कि जब यह ग्राहक में होता है ऐप तो यह एक व्यापार नियम के बजाय एक यूआई या प्रेजेंटेशन नियम है।

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

Answer 3

मेरा वोट स्पष्ट होगा:

• डेटाबेस
• सेवा के सर्वर साइड पर एक व्यापार तर्क परत में किसी अन्य व्यवसाय तर्क चेकों डाल में डेटा अखंडता की जाँच के रूप में ज्यादा डाल
• डाल केवल "फ़ील्ड की आवश्यकता" ग्राहक परत में आदि, बेहतर स्वचालित रूप से डेटाबेस मॉडल से निर्धारित करने या अपने व्यापार मॉडल की तरह सरल जांच

डेटाबेस क्यों?
एसक्यूएल किसी भी आकार या रूप में कुछ बहुत ही बुनियादी और बहुत शक्तिशाली चेक क्षमताओं में है - सुनिश्चित करें कि सामान अद्वितीय है, सुनिश्चित करें कि तालिकाओं के बीच संबंधपरक अखंडता एक दी गई है और इसी तरह - आईटी का उपयोग करें! यदि आप डेटाबेस में इन चेक को करते हैं, तो कोई फर्क नहीं पड़ता कि आपका उपयोगकर्ता अंततः आपके डेटा से कैसे जुड़ता है (डरावनी परिदृश्य: कुछ व्यवसाय इंटेलिजेंस काम करने के लिए प्रबंधक एक्सेल के साथ सीधे आपकी तालिकाओं से कनेक्ट करने में सक्षम होते हैं ......), वे चेक जगह पर होंगे और लागू किया जाएगा। डेटा अखंडता को लागू करना किसी भी प्रणाली में अत्यधिक आवश्यकता है।

सर्वर पर व्यवसाय तर्क क्यों?
वही कारण अन्य उत्तरदाताओं ने उल्लेख किया है: केंद्रीकरण। आप केवल ग्राहक में व्यापार तर्क और अपने चेक नहीं चाहते हैं। क्या होगा यदि आपकी कंपनी या किसी तृतीय पक्ष के बाहरी सलाहकार में कोई अन्य विभाग अचानक आपकी सेवा का उपयोग करना शुरू कर देता है, लेकिन सभी सत्यापन और व्यावसायिक जांच जगह पर नहीं हैं, क्योंकि वे उनके बारे में नहीं जानते हैं ?? नहीं एक अच्छी बात है ...... ग्राहक में

तर्क
हाँ, निश्चित रूप से - तुम भी ग्राहक में कुछ सरल जांच डाल करने के लिए, खासकर अगर यह एक वेब अनुप्रयोग है चाहता हूँ। "इस क्षेत्र की आवश्यकता है" या "इस क्षेत्र के लिए अधिकतम लंबाई" जैसी चीजें जल्द से जल्द लागू की जानी चाहिए। आदर्श रूप में, यह स्वचालित रूप से डेटाबेस/सेवा परत से ग्राहकों द्वारा उठाया जाएगा। एएसपी.नेट सर्वर नियंत्रण में क्लाइंट सत्यापन होता है जिसे स्वचालित रूप से चालू किया जा सकता है, सिल्वरलाइट आरआईए सेवाएं आपके बैकएंड डेटा मॉडल में डेटा प्रतिबंध ले सकती हैं और उन्हें क्लाइंट लेयर में ले जा सकती हैं।