وكائن نقل البيانات إلى هيكلة الكود ، شكل مُدار في بيئة 1C 8.2.

مقدمة

لنبدأ بوصف موجز لمفهوم "النموذج المُدار" والمفاهيم ذات الصلة لمنصة 1C. يمكن لخبراء المنصة تخطي هذا القسم.

أصبح متاحًا في عام 2008 نسخة جديدةالنظام الأساسي 1C: Enterprise 8.2 (يشار إليه فيما يلي باسم التطبيق المُدار) ، والذي يغير تمامًا طبقة العمل بالكامل مع الواجهة. يتضمن ذلك واجهة الأوامر والنماذج ونظام النوافذ. هذا لا يغير فقط نموذج تطوير واجهة المستخدم في التكوين ، ولكنه يقترح أيضًا بنية جديدة لفصل الوظائف بين تطبيق العميل والخادم.
يدعم التطبيق المُدار الأنواع التالية من العملاء:

• عميل سميك (وضع التشغيل العادي والمُدار)
• عميل رفيع
• العميل على شبكة الإنترنت

يستخدم التطبيق المُدار نماذج مبنية عليها تكنولوجيا جديدة. انهم يسمى النماذج المدارة. لسهولة الانتقال ، يتم أيضًا دعم النماذج القديمة (ما يسمى بالنماذج العادية) ، ولكن لم يتم تطوير وظائفها وهي متوفرة فقط في وضع تشغيل العميل الغني.
الاختلافات الرئيسية للنماذج المدارة للمطور:

• وصف تعريفي ، وليس "بالبكسل" للهيكل. يتم وضع العناصر المحددة تلقائيًا بواسطة النظام عند عرض النموذج.
• يتم وصف جميع وظائف النموذج في النموذج تفاصيلو أوامر. التفاصيل هي البيانات التي يعمل بها النموذج ، والأوامر هي الإجراءات التي يتم تنفيذها.
• يتم تنفيذ النموذج على كل من الخادم والعميل.
• في سياق العميل ، لا تتوفر جميع أنواع التطبيقات تقريبًا ، وبالتالي من المستحيل تغيير البيانات في قاعدة المعلومات.
• لكل طريقة أو متغير شكل ، يجب تحديده توجيه التجميع A يحدد ما إذا كان موقع التنفيذ (عميل أو خادم) والوصول إلى سياق النموذج.

فيما يلي التوجيهات الخاصة بتجميع طرق النموذج:

• & AtClient
• & على الخادم
• & OnServerWithoutContext
• & في العميل في ServerWithoutContext

دعنا نوضح ما ورد أعلاه. تُظهر لقطة الشاشة مثالاً على نموذج مُدار ووحدته النمطية في وضع التطوير. ابحث عن وصف تعريفي ، والدعائم ، وتوجيهات التجميع ، وما إلى ذلك.

ستكون جميع المناقشات الإضافية حول الجانب الصحيح من الرسم التوضيحي ، حول كيفية هيكلة رمز الوحدة النمطية والمبادئ التي ستسمح لك بتنفيذ تفاعل فعال بين العميل والخادم.

دعنا نحدد المشكلة

مرت عدة سنوات منذ أن تم استخدام الإصدار الجديد من منصة 1C بشكل نشط وتم إصدار العديد من الحلول (التكوينات) بواسطة كل من 1C والعديد من شركائها.
هل طور المطورون فهمًا مشتركًا لمبادئ التفاعل بين العميل والخادم عند إنشاء النماذج خلال هذا الوقت ، وهل تغير نهج التنفيذ؟ وحدات البرامجفي الواقع المعماري الجديد؟

ضع في اعتبارك بنية الكود (وحدة النموذج) في عدة أشكال من نفس التكوين النموذجي وحاول العثور على أنماط.
تحت الهيكل ، نعني أقسام الكود (غالبًا ما تكون هذه كتل التعليقات) التي يخصصها المطور لتجميع الأساليب والتوجيهات لتجميع هذه الطرق.
مثال 1:
قسم معالج الأحداث الطريقة - على طريقة العميل - على طريقة الخادم - على العميل قسم إجراءات الخدمة ووظائفها وظائف مساعدة التحكم في الإدخال
المثال الثاني:
إجراءات الخدمة ووظائفها مستندات الدفع الأشياء الثمينة معالجات الأحداث
المثال 3:
إجراءات الخدمة على الخادم إجراءات الخدمة على إجراءات خدمة العميل على الخادم بدون سياق معالجات أحداث الأمر معالجات الحدث
المثال 4:
إجراءات الأغراض العامة معالجات أحداث النموذج إجراءات النظام الفرعي "معلومات الاتصال"
في الواقع ، بنية الكود مفقودة ، أو بعبارة ملطفة ، فهي مشابهة لما كان في الصيغ 8.1:

• كلمات غير إعلامية "عام ، خدمة ، مساعدة".
• يحاول خجول فصل أساليب العميل والخادم.
• غالبًا ما يتم تجميع الأساليب حسب عناصر الواجهة "العمل مع المنتجات ذات الأجزاء المجدولة ، معلومات الاتصال".
• الترتيب التعسفي للأساليب ومجموعات الرموز. على سبيل المثال ، قد تكون معالجات الأحداث في الجزء العلوي في أحد النماذج ، وفي الجزء السفلي في شكل آخر ، ولا يتم تمييزها على الإطلاق في الشكل الثالث ، وهكذا.
• ودعونا لا ننسى أن هذا كله ضمن نفس التكوين.
• نعم ، هناك تكوينات تكون فيها الكلمات "عام ، خدمي ، مساعد" دائمًا في نفس الأماكن ، ولكن ...

لماذا تحتاج هيكل كود؟

• تبسيط الصيانة.
• تبسيط التعلم.
• تحديد المبادئ العامة / الهامة / الناجحة.
• ... خيارك

لماذا لا يساعد معيار التطوير الحالي من 1C؟

لنلقِ نظرة على المبادئ المنشورة على أقراص أنظمة النقل الذكية (ITS) وفي العديد من "أدلة المطورين ..." الموصى بها عند كتابة نموذج مُدار.

• قلل عدد مكالمات الخادم.
• الحد الأقصى للحوسبة على الخادم.
• تعد مكالمات الخادم غير السياقية أسرع من استدعاءات السياق.
• برنامج مع وضع التفاعل بين العميل والخادم في الاعتبار.
• إلخ.

هذه شعارات صحيحة تماما ولكن كيف تتحقق؟ كيفية تقليل عدد المكالمات ، ماذا يعني البرنامج في وضع خادم العميل؟

أنماط التصميم أو حكمة الأجيال

تم استخدام التفاعل بين العميل والخادم في تقنيات برمجية مختلفة لعقود. لطالما كانت الإجابة على الأسئلة الموضحة في القسم السابق معروفة وتم تلخيصها في مبدأين أساسيين.

• واجهة بعيدة(يُشار إليها فيما يلي باسم واجهة الوصول عن بُعد)
• كائن نقل البيانات(يشار إليه فيما بعد باسم كائن نقل البيانات)

كلمة لمارتن فاولر ووصفه لهذه المبادئ:

• … يجب أن يحتوي كل كائن يحتمل أن يكون مخصصًا للوصول عن بُعد واجهة منخفضة الدقة، والتي ستقلل من عدد المكالمات المطلوبة لتنفيذ إجراء معين. ... بدلاً من طلب فاتورة وجميع نقاطها بشكل منفصل ، من الضروري قراءة وتحديث جميع نقاط الفاتورة في مكالمة واحدة. يؤثر هذا على بنية الكائن بالكامل ... تذكر: واجهة الوصول عن بُعد لا يحتوي على منطق المجال.
• ... إذا كنت أمًا مهتمة ، فسأقول بالتأكيد لطفلي: "لا تكتب أبدًا كائنات نقل البيانات!" في معظم الحالات ، لا تعد كائنات ترحيل البيانات أكثر من مجموعة الحقول المتضخمة… تكمن قيمة هذا الوحش المثير للاشمئزاز في الاحتمال فقط نقل عناصر متعددة من المعلومات عبر الشبكة في مكالمة واحدة- تقنية ذات أهمية كبيرة للأنظمة الموزعة.

أمثلة على القوالب في منصة 1C

تحتوي واجهة برمجة التطبيقات المتاحة للمطور عند تطوير نموذج مُدار على العديد من الأمثلة على هذه المبادئ.
على سبيل المثال ، أسلوب OpenForm () ، واجهة "خشنة" نموذجية.
OpenParameters = بنية جديدة ("المعلمة 1 ، المعلمة 2 ، المعلمة 3" ، القيمة 1 ، القيمة 2 ، القيمة 3) ؛ Form = OpenForm (FormName، OpenParameters) ؛
قارن مع أسلوب v8.1.
Form = GetForm (FormName) ، Form.Parameter1 = Value1 ؛ Form.Parameter2 = Value2 ؛ Form.Open () ؛

في سياق نموذج مُدار ، مجموعة من "كائنات نقل البيانات". متميز النظاميةو من تحديد المطور.
يقوم النظام بنمذجة كائن تطبيق على العميل ، في شكل عنصر واحد أو أكثر من عناصر بيانات النموذج. لا يمكنك إنشاؤها خارج الارتباط بتفاصيل النموذج.

• هيكل البيانات
• تجميع البيانات
• DataFormStructureCollection
• DataFormsTree

يتم تحويل كائنات نظام نقل البيانات إلى أنواع التطبيقات والعكس بالطرق التالية:

• ValueVDataForm ()
• FormDataToValue ()
• CopyFormData ()
• ValueVFormProps ()
• FormAttributeToValue ()

غالبًا ما يتم استخدام تحويل صريح عند تكييف حل موجود. قد تتوقع الأساليب (ميزة) معلمات إدخال مثل ValueTable بدلاً من FormDataCollection ، أو تم تعريف الطريقة في سياق كائن التطبيق وأصبحت غير متاحة للاتصال المباشر من النموذج.
مثال 1C v8.1:
// على العميل في سياق النموذج FillUsersCache (DepartmentReference)
مثال 1C v8.2:
// على الخادم في سياق النموذج ProcessingObject = FormAttributeToValue ("الكائن") ؛ ProcessingObject.FillCacheUsers (DepartmentReference) ، ValueVFormAttribute (ProcessingObject، "كائن") ،

كائنات ترحيل البيانات ، التي تم تحديد هيكلها من قبل المطور ، هي مجموعة فرعية صغيرة من الأنواع المتاحة على كل من العميل والخادم. في أغلب الأحيان ، كمعلمات ونتائج طرق للواجهة "الخشنة" ، يتم استخدام ما يلي:

• أنواع بدائية (سلسلة ، رقم ، منطقي)
• بنية
• المطابقة
• مجموعة مصفوفة
• روابط إلى كائنات التطبيق (معرف فريد وتمثيل نصي)

مثال: يقبل الأسلوب قائمة الطلبات لتغيير الحالة ويعيد وصف الأخطاء إلى العميل.
& OnServerWithoutContext Function ServerChangeOrderStatus (الطلبات ، NewStatus) أخطاء = تطابق جديد () ؛ // [order] [وصف الخطأ] لكل طلب من حلقة الطلبات StartTransaction () ؛ محاولة DocOb = Order.GetObject () ، …. إجراءات أخرى ، ربما ليس فقط مع الأمر ... استثناء CancelTransaction () ؛ Errors.Insert (Order، DescriptionError ()) ؛ نهاية المحاولة نهاية الدورة عودة الخطأ ؛ EndFunction // ServerChangeOrderStatus ()

هيكلة الكود

الأهداف الرئيسية التي يجب أن تعكسها وحدة النموذج المدارة وأساليب الحل.

• فصل واضح بين كود العميل والخادم.دعونا لا ننسى أنه في وقت التنفيذ ، هناك عمليتان متفاعلتان ، تختلف الوظائف المتاحة في كل منهما اختلافًا كبيرًا.
• تحديد واضح لواجهة الوصول عن بعد ، ما هي طرق الخادم التي يمكن استدعاؤها من العميل ، وأيها لا يمكن؟ تبدأ أسماء أساليب الواجهة البعيدة بالبادئة "Server". يسمح لك هذا برؤية انتقال عنصر التحكم على الفور إلى الخادم عند قراءة التعليمات البرمجية ، ويبسط استخدام التلميحات السياقية. لاحظ أن التوصية الرسمية (ITS) تقترح طرق تسمية مع الإصلاحات اللاحقة ، مثل ChangeOrderStatusOnServer (). ومع ذلك ، للتكرار ، لا يمكن استدعاء جميع طرق الخادم من العميل ، وبالتالي فإن إمكانية الوصول المنطقية أكثر أهمية من موقع التجميع. لذلك ، باستخدام البادئة "Server" ، نحدد فقط الطرق المتاحة للعميل ، وسيسمى أسلوب المثال ServerChangeOrderStatus ().
• مقروئية.من باب الذوق ، نقبل الطلب عندما تبدأ الوحدة بإجراءات إنشاء نموذج على الخادم وطرق الوصول عن بُعد.
• قابلية الصيانة.يجب تحديد مكان إضافة رمز جديد بوضوح. نقطة مهمة، والتي يتم إنشاؤها تلقائيًا بواسطة أداة تهيئة كعب الأسلوب ، تتم إضافتها إلى نهاية الوحدة النمطية. نظرًا لأنه يتم غالبًا إنشاء معالجات أحداث عنصر النموذج تلقائيًا ، يتم وضع الكتلة المقابلة أخيرًا حتى لا يتم سحب كل معالج إلى مكان آخر في الوحدة النمطية.

يوجد أدناه الهيكل الأساسي للوحدة النمطية التي تنفذ الأهداف المدرجة.

• خيار رسومي - يوضح بوضوح التدفق الرئيسي للتنفيذ.
• الإصدار النصي هو مثال لتصميم نموذج لـ إدخال سريعالهياكل في شكل وحدة نمطية جديدة.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""التاريخ =""/> // <Описание> // // ////////////////////////////////////////////////////// / ////////////////////////////// // MODULE VARIABLES ///////////////// / ///////////////////////////////////////////////////// // // ////////////// // ON THE SERVER // ******* الأحداث على الخادم ******* & On The Server Procedure On CreationOn The Server ( فشل ، معالجة قياسية) // أدخل محتويات المعالج EndProcedure // ******* واجهة الوصول عن بُعد ******* // ******* منطق الأعمال على الخادم **** *** ///////// //////////////////////////////////////// ///////////// ///////////////////// // COMMON CLIENT AND SERVER METHODS ///////// /////////////// /////////////////////////////////////// //////////////// //////// // ON THE CLIENT // ******* منطق الأعمال على العميل ******* // ******* COMMANDS ******* // ******* الأحداث على العميل ****** ////////////// //////////////////// ////////////////////////////////// /////////////////// / / مشغلو البرنامج الرئيسيون

أسئلة ذات صلة

في الختام ، نحدد بعض المجالات التي من المفيد التفكير فيها عند برمجة تفاعل بين العميل والخادم.

• خيارات لتنفيذ واجهة الوصول عن بعد. عدم التزامن ، التفصيل ...
• التخزين المؤقت. 1C اتخذت قرارًا معماريًا مؤسفًا ، حيث قدمت التخزين المؤقت فقط على مستوى طرق استدعاء الوحدات النمطية الشائعة ولم توفر خيارات التحكم (وقت محدث ، إعادة التعيين عند الطلب).
• مكالمات الخادم الضمنية. لا تنس الميزات التكنولوجية ، فالعديد من العمليات "غير الضارة" على العميل تستفز النظام الأساسي للوصول إلى الخادم.

11.12.2016

حول النماذج المُدارة 1C (البداية)

عميل رفيع

لا يوجد مكان أرق. الآن لا يقوم تطبيق العميل بالاستعلام عن قاعدة البيانات (هذا هو عمل الخادم). يعرض تطبيق العميل ببساطة الواجهة والبيانات.

تجدر الإشارة إلى أن بنية الكود أصبحت أكثر تعقيدًا بسبب هذه التحولات. على العميل ، لا توجد مراجع ، كائنات ، جدول قيم ... تتوفر فقط الأنواع الأولية (سلسلة ، تاريخ ، منطقي ، مصفوفة ، هيكل ...). هذا يعني أنه يجب على المبرمج الآن التفكير فيما يجب الحصول عليه على الخادم ، وكيفية القيام بذلك بأقل تكلفة.

التفاعل بين العميل والخادم

سمح لنا نهج جديد للتفاعل بين العميل والخادم بإنشاء نموذج جديد لواجهة المستخدم. الآن تم إعلان الواجهة (!) يبدأ تصميم الواجهة بالبيانات والتفاصيل والأجزاء المجدولة. عند إنشاء خاصية ، عليك التفكير في الشكل الذي ستبدو عليه في الواجهة ، وما إذا كانت مطلوبة ، وكيفية ارتباطها بالدعامات الأخرى ...

لا يوجد سياق (حالة) على الخادم

يعمل خادم 1C على مبدأ "عديمي الجنسية" (اللغة الإنجليزية بدون دولة). هذا يعني أن الخادم لا يستجيب إلا للطلبات ، وفي نفس الوقت لا يخزن أي شيء بين طلبين (هناك تخزين مؤقت لهذا الغرض).

FormDataToValue ، FormDataCollection ، FormData ...

لجأنا إلى الخادم ، وفعل كل شيء من أجلنا ، وحذف البيانات ونسي أننا أتينا. ستساعدنا جميع الكائنات المسماة "FormData" + "شيء هناك" على حفظ بياناتنا بين مكالمتين للخادم.

التخزين المؤقت

التخزين المؤقت هو مكان خاص حيث (بالإضافة إلى تفاصيل النموذج) يمكنك حفظ الحالة على الخادم. يمكن للتخزين تخزين البيانات غير المتوفرة على العميل (أي التي لا يمكن وضعها في تفاصيل النموذج).

للعمل مع التخزين المؤقت ، استخدم أساليب MoveToTempStorage () بناء الجملة: PlaceToTempStorage (<Данные>, <Адрес>) الوصف: يخزن قيمة قابلة للتسلسل في التخزين المؤقت. التوفر: عميل رفيع ، عميل ويب ، خادم ، عميل سميك ، اتصال خارجي ، تطبيق جوال (عميل) ، تطبيق محمول (خادم). يقوم استدعاء الأسلوب بإجراء مكالمة إلى الخادم.<Адрес>(اختياري) النوع: معرف فريد ؛ خط. المعرّف الفريد للنموذج الذي سيتم تخزين البيانات فيه مؤقتًا وسيتم إرجاع العنوان الجديد. أو العنوان في التخزين المؤقت حيث يجب وضع البيانات. يجب الحصول على العنوان مسبقًا باستخدام هذه الطريقة. إذا تم تمرير نموذج UniqueIdentifier أو عنوان في المخزن ، فسيتم حذف القيمة تلقائيًا بعد إغلاق النموذج. إذا تم تمرير UniqueIdentifier ليس معرفًا فريدًا للنموذج ، فسيتم حذف القيمة عند انتهاء جلسة المستخدم. إذا لم يتم تحديد المعلمة ، فسيتم حذف القيمة الموضوعة بعد طلب الخادم التالي من الوحدة النمطية المشتركة ، في مكالمات خادم السياق وغير السياق من النموذج ، على مكالمات الخادم من وحدة الأوامر ، أو عند الحصول على النموذج. ملاحظة: التخزين المؤقت الذي تم إنشاؤه في جلسة واحدة لا يمكن الوصول إليه من جلسة أخرى. الاستثناء هو القدرة على نقل البيانات من وظيفة في الخلفية إلى الجلسة التي بدأت وظيفة الخلفية باستخدام التخزين المؤقت. لمثل هذا النقل ، في الجلسة الرئيسية ، ضع قيمة فارغة في التخزين المؤقت ، لتمرير معرف النموذج. ثم قم بتمرير العنوان المستلم إلى وظيفة الخلفية من خلال معلمات وظيفة الخلفية. علاوة على ذلك ، إذا تم استخدام هذا العنوان في المعلمة<Адрес>، سيتم نسخ النتيجة إلى الجلسة التي بدأت منها وظيفة الخلفية. لن تكون البيانات الموضوعة في التخزين المؤقت في وظيفة الخلفية متاحة من الجلسة الأصلية حتى تكتمل وظيفة الخلفية. و GetFromTempStorage () بناء الجملة: GetFromTempStorage (<Адрес>) الوصف: الحصول على قيمة من التخزين المؤقت. التوفر: عميل رفيع ، عميل ويب ، خادم ، عميل سميك ، اتصال خارجي ، تطبيق جوال (عميل) ، تطبيق محمول (خادم). يقوم استدعاء الأسلوب بإجراء مكالمة إلى الخادم. ملاحظة: لا يتم تخزين نتيجة التنفيذ مؤقتًا ، يتم استدعاء الخادم في كل مرة يتم استدعاء الطريقة.

استدعاء رمز الخادم

أي مكالمة إلى رمز الخادم تقوم دائمًا بإجراء تسلسل للبيانات المرسلة. يتم حزم جميع المعلمات في شكل سلسلة ويتم نقلها عبر الشبكة. يتم أيضًا نقل نتيجة العمل مرة أخرى في شكل متسلسل ، حيث يتم استعادتها بعد ذلك إلى كائنات مألوفة.

إحالة أعلام الوحدة

• تشير العلامة إلى مكان تجميع رمز الوحدة النمطية (على الخادم ، على العميل ، في اتصال خارجي)
• إذا تم تجميع وحدة في أماكن متعددة ، فستكون مرئية فقط وفقًا للإعلام
• يمكن نقل تنفيذ التعليمات البرمجية فقط في حالة عدم وجود وحدة تسمى في سياق التنفيذ الحالي ، ولكنها موجودة في مكان آخر (إذا كانت الوحدة النمطية موجودة فقط على الخادم ، ولم تكن موجودة على العميل ، فسيتم استدعاء الخادم)

علم استدعاء الخادم

بدءًا من النظام الأساسي 1C: Enterprise 8.2 ، تمت إضافة علامة "استدعاء الخادم". وهو ما يساعد فقط على "حل" شروط الانتقال إلى جهاز آخر. إذا تم تعيين هذه العلامة للوحدة النمطية ، فستكون الوحدة مرئية من العميل ، وإذا لم يكن الأمر كذلك ، فستؤدي محاولة الاتصال من العميل إلى حدوث خطأ. لن يكون رمز الوحدة مرئيًا ، كما لو أنه غير موجود على الإطلاق.

وبالتالي ، في عميل سميك عادي ، لا يمكنك نقل الكود إلى الخادم إلا إذا اتصلت بوحدة نمطية مشتركة من العميل ، والتي من أجلها:

• تم تحديد خانة اختيار الخادم
• تم تحديد مربع الاختيار "خادم الاتصال"
• تمت إزالة جميع مربعات الاختيار "العميل"

مع ظهور النظام الأساسي 1C Enterprise 8.2 ، تغيرت آلية تطوير واجهة المستخدم بشكل كبير. يمكنك الآن إنشاء نماذج وتطبيقات مُدارة (الشكل 1).

الصورة 1

بالإضافة إلى ذلك ، تم اقتراح نظام جديد لفصل الوظائف بين تطبيق العميل والخادم.
يدعم التطبيق المُدار الأنواع التالية من العملاء:

• عميل سميك (وضع التشغيل العادي والمُدار) ،
• عميل رفيع
• العميل على شبكة الإنترنت.

تختلف آلية إنشاء النماذج المُدارة اختلافًا كبيرًا عن النماذج التقليدية. بادئ ذي بدء ، تختلف النماذج المُدارة من حيث أنها يتم إنشاؤها تلقائيًا بواسطة النظام بناءً على إعدادات خاصة ؛ والآن لا يحتاج المبرمج إلى رسم كل نموذج بالتفصيل. يتم وصف جميع وظائف النموذج في شكل تفاصيل وأوامر. التفاصيل هي البيانات التي يعمل بها النموذج ، والأوامر هي الإجراءات التي يتم تنفيذها. لكل طريقة أو متغير نموذج ، يجب تحديد توجيه تجميع ، والذي يحدد مكان التنفيذ (العميل أو الخادم). يمكن أن تكون توجيهات التجميع:

• & AtClient ،
• & على الخادم ،
• & OnServerWithoutContext ،
• & في العميل في ServerWithoutContext.

يختلف النموذج المُدار أيضًا عن النموذج العادي في أنواع البيانات التي يعمل معها. إذا كان النموذج العادي يعمل مع معظم الأنواع التي يوفرها 1C: Enterprise (بما في ذلك الأنواع DirectoryObject ، و DocumentObject ، وما إلى ذلك) ، فيمكن تمييز فئات الأنواع التالية في نموذج مُدار:

• الأنواع التي يتم استخدامها مباشرة في النموذج هي تلك الأنواع الموجودة على جانب العميل الرقيق وعميل الويب (على سبيل المثال ، Number ، ReferenceReference.Products ، GraphicScheme ، SpreadsheetDocument) ؛
• الأنواع التي سيتم تحويلها إلى أنواع بيانات خاصة هي أنواع بيانات النماذج المُدارة. يتم عرض هذه الأنواع في قائمة سمات النموذج بين قوسين ، على سبيل المثال (CatalogObject.Products) ؛
• قائمة ديناميكية.

يتميز عمل النماذج المدارة بالسمات المميزة التالية (الشكل 2):

• النموذج موجود على كل من العميل والخادم.

يقوم بالتفاعل بين العميل والخادم (نقل البيانات وخصائص تصميم العناصر).

• لا يعمل النموذج مع كائنات التطبيق

الشكل 2

يستخدم النموذج كائنات عامة خاصة
نماذج البيانات(الشكل 3).


الشكل 3

تعمل كائنات التطبيق فقط على الخادم وخلال عمليات معينة فقط.
عند فتح النموذج:

• تتم قراءة الكائن من قاعدة البيانات ،
• يتم تحويل الكائن إلى بيانات النموذج ،
• تمت إزالة الكائن (من الذاكرة) ،
• يتم تمرير بيانات النموذج إلى العميل.

عند التسجيل:

• يتم استلام بيانات النموذج من العميل ،
• يتم تحويل بيانات النموذج إلى كائن ،
• يتم كتابة الكائن في قاعدة البيانات ،
• يتم إزالة الكائن (من الذاكرة).

في الدرس الأخير ، فكرنا في عميل عادي (سمين). في إصدار المنصة 1C 8.2. يستخدمون أشكال الشاشة الجديدة 1C 8.2. يطلق عليهم النماذج المدارة 1C 8.2.

النماذج المدارة 1C 8.2 هي مستقبل 1C. وهي تختلف عن النماذج العادية 1C 8.2 من حيث أنها يتم إنشاؤها تلقائيًا بواسطة النظام بناءً على إعدادات خاصة (يتم رسم النماذج "العادية" ببساطة بواسطة المبرمج حسب الرغبة).

الاختلافات في تطوير النماذج المدارة 1C 8.2 من الأشكال المعتادة كبيرة. لذلك ، اجتمعنا اليوم لمناقشة إنشاء وتعديل النماذج المُدارة 1C 8.2.

النماذج المدارة 1C 8.2

إذا كنت تقوم بتطوير تكوينات 1C من قبل ، عند فتح محرر النماذج المدارة 1C 8.2 ، فسوف تشعر بالحيرة على الفور من حقيقة أنه من المستحيل التأثير على نموذج 1C 8.2 بالماوس على الإطلاق.

لا يمكنك تغيير نموذج 1C 8.2 ، ولا يمكنك نقل العنصر ، ولا يمكنك حتى عرض خصائص الحقل كما كان من قبل - بالنقر المزدوج على الحقل في نموذج 1C 8.2.

الآن الأساس لتطوير نموذج 1C 8.2 ليس ربط الحقول بالإحداثيات الموجودة في النموذج ، ولكن الإعدادات الخاصة. يقوم النظام تلقائيًا بإنشاء نموذج مُدار 1C 8.2 بناءً على هذه الإعدادات.

تتكون الإعدادات من قائمة عناصر النموذج 1C 8.2 الموجودة في المحرر في الزاوية اليسرى العليا. تتضمن عناصر النموذج 1C 8.2 ما يلي:

• المتطلبات
• قد تبدو الأوامر (المفهوم الجديد 1C 8.2 مثل الأزرار أو عناصر القائمة)
• المجموعات (لدمج التفاصيل والأوامر).

وفقًا لذلك ، لا توجد إعدادات هذه العناصر في خصائص الحقول ، ولكن في خصائص عناصر الإعدادات هذه (قائمة النقر بزر الماوس الأيمن ، عنصر الخصائص).

كيف تعمل النماذج المدارة 1C 8.2

يختلف العمل مع النماذج المُدارة 1C 8.2 بالنسبة للمستخدم. لديهم المزيد من الميزات ، ولكنها غير معتادة بالنسبة لأولئك الذين يعملون مع 1C لفترة طويلة.

بادئ ذي بدء ، يختلف موقع العناصر المعتادة في النموذج 1C 8.2. يكون شريط الأوامر دائمًا في الأعلى.

الجانب الأيسر من شريط الأوامر قابل للتخصيص. عادة ما تحتوي على أزرار نموذجية مثل التسجيل والنشر.

الجانب الأيمن من لوحة القيادة هو القائمة القياسية الجديدة لنموذج 1C جميع الإجراءات. تتيح لك هذه القائمة إدارة نموذج 1C 8.2 كما يحلو لك ، على غرار الطريقة التي تسمح لك بها الإعدادات في تقرير ACS بتغيير مظهر التقرير بشكل كبير.

عناصر القائمة التعسفية 1C جميع الإجراءات

اعتمادًا على ما إذا كان هذا النموذج 1C 8.1 ينتمي إلى واحد أو آخر ، تمتلئ القائمة بالعناصر التي تسمح لك بإدارة هذا الكائن. على سبيل المثال ، إذا كان نموذج قائمة دليل ، فستكون هناك أوامر مثل إنشاء أو تحرير.

عنصر قائمة تخصيص قائمة 1C كافة الإجراءات

إذا كانت هناك قائمة في نموذج 1C 8.2 ، فستحتوي القائمة على الأمر قائمة الإعداد وقائمة العرض.
إذا كان أمر قائمة الإخراج مألوفًا لك بالفعل - فهو يسمح لك بحفظ أي قائمة في 1C في Excel / طباعته ، ثم يكون الأمر الثاني جديدًا.

كما لاحظت بالفعل ، لا يوجد المزيد من أزرار التحديد على شريط أوامر القوائم. بدلاً من ذلك ، ظهر زر البحث ، الذي يعمل (بالإضافة إلى وضع المؤشر المعطل الآن في القائمة عند الكتابة) - هناك شكاوى.

بطبيعة الحال ، لا يمكن مقارنة وظيفة زر البحث بالاختيارات ، لكنها لم تختف في أي مكان!
هم الآن ضمن عنصر قائمة تخصيص القائمة. يمكن الآن إجراء التحديد بواسطة أي حقل ، وبالإضافة إلى ذلك ، يمكن إجراء الفرز والتنسيق الشرطي بنفس الطريقة التي يمكن إجراؤها في تقارير SKD.

نموذج قائمة تغيير العنصر 1C جميع الإجراءات

يسمح لك عنصر "تغيير النموذج" بتغيير ليس فقط القائمة الموجودة في النموذج 1C 8.2 ، ولكن أيضًا النموذج 1C 8.2 نفسه.

يمكن للمستخدم بشكل مستقل تمكين أو تعطيل رؤية الحقول في نموذج 1C 8.2 ، والعرض والارتفاع ، وتفعيل الحقل الافتراضي عند الفتح ، وما إلى ذلك.

استخدام النماذج المدارة 1C 8.2 والنماذج التقليدية 1C

بشكل افتراضي ، تُستخدم نماذج 1C العادية في تكوينات لعميل 1C سميك (عادي) ، وتُستخدم النماذج المُدارة في تكوينات لعميل رفيع وعلى الويب 1C. ومع ذلك ، يمكن استخدام كلا شكلي 1C في أي تكوين ، بما في ذلك في وقت واحد.

للقيام بذلك ، يجب عليك أيضًا إدخال خصائص التكوين (العنصر العلوي في نافذة التكوين).

في خصائص التكوين في 1C 8.2 ، ظهر مربعا اختيار جديدان يسمحان لك بتمكين الاستخدام غير القياسي لنماذج 1C.

إنشاء النماذج المدارة 8.2

تتم إضافة نموذج جديد 1C 8.2 بنفس الطريقة كما كان من قبل - باستخدام زر Ins على لوحة المفاتيح أو الزر Add. لإدخال واحدة موجودة ، انقر نقرًا مزدوجًا عليها بالماوس.

بشكل افتراضي ، سيتم إنشاء النموذج (عادي أو مُدار) الذي تم تعيينه في التكوين (راجع خاصية وضع التشغيل الرئيسي في خصائص التكوين). النماذج.

سيطالبك المُنشئ باختيار نوع النموذج - شكل عنصر ، قائمة. هنا يمكنك إضافة أو إزالة أشرطة الأوامر في النموذج. في أغلب الأحيان ، يتم ترك هذه الإعدادات كما هي افتراضيًا.

يتم فتح نموذج يتم ملؤه افتراضيًا - كل تفاصيل كائن 1C التي تمت إضافتها إليه. يمكنك تحديد قائمة محددة من الحقول المطلوبة في علامة التبويب الثانية للمنشئ.

يتكون محرر النموذج من ثلاثة أقسام.

• في الزاوية اليسرى العلوية قائمة من عناصر النموذج. يتكون من الحقول والأوامر والمجموعات التي تسمح لك بدمج العناصر. يمكن عرض قائمة الأوامر بشكل منفصل في علامة التبويب واجهة الأوامر.
• توجد في الزاوية اليمنى العليا قائمة بسمات النموذج المتاحة وسمات الكائن (افتح علامة التقاطع بجوار سمة الكائن).
• يوجد أدناه معاينة للنموذج الناتج.

يمكنك سحب التفاصيل المتاحة إلى اليسار وستصبح عنصر نموذج (حقل في النموذج).

إذا كنت بحاجة إلى إضافة زر أو عنصر قائمة - على الجانب الأيمن من علامة التبويب الأوامر ، فأنت بحاجة إلى إنشاء أمر جديد. هذا هو غلاف لوظيفة في وحدة نموذجية. بالإضافة إلى تحديد الوظيفة التي سيتم استدعاؤها بالفعل ، يمكنك تعيين تمثيل - على سبيل المثال ، صورة ، وكذلك اعتماد الرؤية على خيار وظيفي.

يتم سحب الأوامر أيضًا إلى اليسار. إذا كان الوالد هو شريط أوامر ، فسيكون زر شريط الأوامر - وإلا سيكون مجرد زر.

في قائمة عناصر النموذج (الحقول) ، لا يمكنك فقط سحب سمة الكائن / النموذج ، ولكن يمكنك أيضًا إضافتها ببساطة (الزر "إضافة" أو "إضافات"). على وجه الخصوص ، يمكنك إنشاء كائن نموذج جديد - مجموعة.

يمكن أن تكون المجموعة لوحة أوامر (يجب أن يكون المؤشر على سطر النموذج). ثم تقوم بسحب الأوامر إليه وتصبح أزرارًا.

يمكن أن تكون المجموعة "منتظمة". ثم إنها طريقة لتجميع الحقول رأسيًا وأفقيًا. يمكن إزالة اسم المجموعة من الخصائص.

يمكن أن تكون المجموعة لوحة (صفحات). أعلى مجموعة مضافة هي لوحة ، والمجموعات المتداخلة من هذا النوع هي الصفحات. يتم بالفعل سحب الحقول إلى الصفحات.

تتم إزالة عناصر النموذج غير الضرورية عن طريق حذف عناصر النموذج في القائمة.
يتم تحديد موضع الحقل في النموذج بالترتيب في قائمة العناصر (رأسيًا) أو حسب المجموعات (أفقيًا). يتم تعيين العرض والارتفاع في خصائص عنصر النموذج.

تم توسيع خصائص عنصر النموذج بشكل كبير وتحتوي على العديد من الأشياء المفيدة - التحكم في المظهر (أزرار الاختيار والمسح) والتحقق من القيم الافتراضية.

يتم تعيين خصائص النموذج نفسه ، بما في ذلك أبعاده ، في العنصر الجذر للنموذج الذي يحمل نفس اسم النموذج.

معالجات الأحداث (الاستجابة لإجراءات المستخدم) مقسمة الآن إلى نوعين. القديمة - كما كان من قبل ، تم تحديدها في خصائص النموذج والحقول (على سبيل المثال ، عند التغيير وعند فتح النموذج). جديد - أصبحت أوامر وتستخدم لعناصر القائمة والأزرار.

من إصدار النظام الأساسي 8.2 ، بدأت 1C في استخدام مبادئ جديدة لبناء الواجهة وتفاعل المستخدم مع قاعدة البيانات. التكنولوجيا الجديدة تسمى التطبيق المدار. خضعت آليات بناء النماذج ونظام التفاعلات بين مستخدم خادم 1C وقاعدة البيانات لأكبر معالجة. لا يزال الوضع العادي مدعومًا من النظام الأساسي ، ولكن بمرور الوقت ، سيتحول جميع مستخدمي 1C إلى النماذج المُدارة.

بالنسبة للمستخدمين العاديين ، يختلف الشكل المُدار لمستند 1C عن النموذج المعتاد فقط في المظهر. بالنسبة للمطور ، هذه آلية جديدة لها قواعدها وقوانينها وشروطها. خضعت العديد من المجالات للتغيير ، لكن الابتكارات التالية تعتبر أساسية بين مطوري 1C ذوي الخبرة:

• تشكيل مستقل لهيكل النموذج ووضع الحقول بواسطة المنصة. إذا وصف المطورون السابقون موضع الحقل عن طريق تحديد وحدات البكسل ، فمن الممكن الآن فقط تحديد نوع التجميع ؛
• يتكون النموذج من سمات تمثل بيانات النموذج ، والأوامر - الإجراءات والوظائف التي يتم تنفيذها ؛
• يتم تنفيذ كود النموذج على جانبي الخادم والعميل. بعد كل شيء ، النموذج نفسه هو كائن تكوين تم إنشاؤه على الخادم وعرضه على العميل. هذا يعني أنه يجمع بين أجزاء العميل والخادم ؛
• من جانب العميل ، أصبحت العديد من أنواع البيانات غير متوفرة والآن لا توجد طريقة لتغيير البيانات في قاعدة المعلومات ؛
• لكل إجراء أو وظيفة ، يجب تحديد إعداد خاص - توجيه تجميع. إنه مسؤول عن المكان الذي يتم فيه تنفيذ الكود ويمكن أن يأخذ القيم التالية:
  • على العميل
  • على الخادم
  • على ServerWithoutContext ؛
  • OnClientOnServer ؛
  • على العميل على الخادم بدون سياق.

النقطة الأخيرة حادة بشكل خاص في وضع النماذج المدارة. إذا لم يكن المطور على دراية جيدة بالتوجيهات أو التفاعل بين العميل والخادم ، فسيكون من الصعب جدًا عليه إنشاء نموذج مُدار. تتحد جميع المبادئ الجديدة لبناء النماذج المُدارة في 1C: Enterprise 8.3 بالمفهوم العام للبنية ثلاثية المستويات. يتضمن أجهزة كمبيوتر العميل وخادم 1C ونظام إدارة قواعد البيانات حيث يتم تخزين البيانات.

أصبح تحرير نموذج مُدار في أداة التهيئة مختلفًا أيضًا. لقد تغيرت العديد من الجوانب وقد يفاجأ مطورو الإصدار 7.7 ، حيث لا توجد نماذج مُدارة. حتى مظهر مصمم النموذج قد تغير ، والذي يمكن رؤيته من خلال فتح أي من أشكال كائن التكوين. عند فتح كائن ما ، نرى نافذة مقسمة إلى عدة أقسام:

1. عناصر واجهة النموذج. في الجزء العلوي الأيسر توجد نافذة تسرد جميع الحقول المعروضة في النموذج المحدد ، والتي تضمن تفاعل البرنامج مع المستخدم ؛
2. تفاصيل النموذج. في أعلى اليسار توجد جميع البيانات التي يعمل بها النموذج. في نفوسهم يتم تخزين المعلومات على جانب العميل ؛
3. عرض نموذج مُدار. أدناه نرى معاينة للشكل بناءً على عناصر الواجهة ؛
4. وحدة النموذج. قسم يحتوي على الإجراءات والوظائف التي يستخدمها هذا النموذج. هنا يمكنك العثور على رمز الخوارزميات لتفاعل البرنامج مع كل من المستخدم وقاعدة البيانات.

يحث مطورو 1C العملاء على التبديل إلى النماذج المُدارة ، لذا فإن تعلم مبادئ تطوير النماذج المُدارة هو مسألة وقت. عند بدء العمل بهذا النوع من النماذج ، ستفهم أن هذه خطوة نحو توحيد معايير التطوير والامتثال للقواعد الموحدة. لذلك ، فإن القدرة على العمل مع النماذج المدارة في 1C 8.3 تزيد من مستواك كمطور 1C.

إرشادات لتصميم النماذج المدارة

بادئ ذي بدء ، لفهم آلية الوضع المُدار 1C ، يجب أن تتذكر أن النموذج موجود على كل من الخادم والعميل. علاوة على ذلك ، بالنسبة للعميل ، هذا الكائن هو مجرد صورة لواجهة تفاعل المستخدم مع البرنامج. يجب أن تتم جميع العمليات الحسابية والخوارزميات والحسابات والمعالجة على جانب الخادم فقط. لا يقتصر ذلك على عدم القدرة على استخدام العديد من الوظائف والمعلمات على العميل ، ولكن أيضًا من خلال متطلبات الأداء.

يمكنك معرفة مكان تنفيذ الإجراء من خلال اسم التوجيه ، والذي يجب كتابته قبل كل إجراء ووظيفة في وحدة النموذج. تشير الصياغة "بدون سياق" إلى أن البيانات الموجودة في النموذج المُدار لن يتم تمريرها إلى هذا الإجراء على الخادم. وبالتالي ، في مثل هذه الإجراءات ، لن يكون من الممكن كتابة خوارزميات بناءً على القيم التي أدخلها المستخدم. إذا لم يتم تحديد هذه الصياغة ، فسيتم إرسال النموذج بالكامل مع جميع التفاصيل ، ويمكنك الوصول إليها.

يوصي مطورو 1C بشدة باستخدام استدعاءات الخادم غير المرتبطة بالسياق ، وتقليل عددها قدر الإمكان ومحاولة عدم إجراء العمليات الحسابية على العميل. يصعب على المطورين المبتدئين الذين ليس لديهم خلفية نظرية الامتثال لجميع هذه القواعد وتغيير الكود بشكل صحيح. قبل أن تبدأ العمل بمفردك ، سيكون من المفيد فتح نموذج تكوين مُدار ، وإلقاء نظرة على بناء الجملة وكيفية تفاعل العميل والخادم.

&НаСервере Процедура ПолучитьПлатежноРасчетныеДокументыИзХранилища(НовыйАдресВХранилище) &НаСервереБезКонтекста Функция ЕстьРасчетыСКлиентом(ДокументОснование) &НаСервереБезКонтекста Процедура ЗаполнитьСписокВыбораКПП(СписокВыбора, Контрагент, ДатаСведений) &НаКлиенте Процедура ЗаполнитьГоловногоКонтрагентаЗавершение(ВыбранноеЗначение, ДополнительныеПараметры) &НаСервере Процедура УстановитьТекстПлатежноРасчетныхДокументов() &НаСервере Функция ЕстьЗаполненныеИсходныеДокументы()

ستكون القواعد الجديدة لتطوير نماذج 1C ذات فائدة كبيرة إذا التزم بها جميع المطورين. علاوة على ذلك ، سيشعر الجميع بالتغييرات نحو الأفضل - المبرمجون والشركات العاملة في 1C وأصحاب الامتياز ومطورو 1C. النتائج الرئيسية للتشغيل الصحيح للنماذج المدارة في 1C:

1. سهولة صيانة التكوين وزيادة قابلية قراءة الكود. من هذا يمكننا أن نستنتج أن الخوارزمية التي يكتبها أحد المطورين يمكن دائمًا تصحيحها بواسطة موظف آخر دون قضاء الكثير من الوقت ؛
2. فصل الكود الذي يعمل على العميل والخادم. بالنظر إلى مدى اختلاف الوظائف المتاحة على كل جانب ، فإن الفصل بينهما سيكون الخطوة الصحيحة ؛
3. يتمتع المطورون بفهم أعمق لمنطق النظام الأساسي والتفاعلات بين العميل والخادم والخوارزميات التي يكتبونها. في الإصدارات 8.0 وما قبلها ، كان من الشائع جدًا العثور على نماذج من المستندات أو الدلائل التي تم تطويرها دون فهم جزء الخادم والعميل ؛
4. زيادة سرعة التكوينات وتقليل الحمل على أجهزة الكمبيوتر العميلة ؛
5. تقليل تكلفة شراء أجهزة كمبيوتر لأماكن العمل بسبب عدم الحاجة إلى شراء أجهزة كمبيوتر قوية.

يمكن أن يجلب اختيار النموذج المُدار باعتباره وضع التشغيل الرئيسي 1C العديد من المفاجآت. ولكن مع النهج الصحيح ، ستحقق هذه الخطوة أرباحًا كبيرة ، لذلك يتخذها المزيد والمزيد من مستخدمي 1C في جميع أنحاء روسيا. مع الأخذ في الاعتبار حقيقة أن شركة 1C تعول على تطوير النماذج المدارة في المستقبل ، فمن الخطر البقاء على النماذج التقليدية القديمة.