هل هناك طريقة مقبولة بشكل عام لإضافة معلومات التعريف إلى عناصر المصفوفة للإشارة إلى كيفية التعامل معها؟

Question

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

على سبيل المثال، بيانات عنصر الصفيف...

• ...يمكن عرضها كرابط:ثم أريد إرفاق معلومات الرابط.يمكن للكود الذي ينشئ html من المصفوفة استخدامه لإنشاء رابط.
• ...هو تاريخ النموذج 2009-09-14:ثم أريد أن أشير إليه بطريقة أو بأخرى على أنه تاريخ.إذا كان الاستخدام لصفحة html، فيمكن بعد ذلك عرضها بشكل أكثر جمالًا إلى حد ما، على سبيل المثال. مو 14 سبتمبر أو اليوم;إذا كان المستلم ملف CSV فمن الأفضل تركه.

هل هناك طريقة أفضل الممارسات لحل هذه المشكلة؟

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

1. قم بتخزين كل عنصر صفيف ككائن تم إنشاؤه خصيصًا (تاريخ، قابل للربط، نص...)، بدلاً من وجود عنصر الصفيف كنص.ربما توفر الافتراضي .to_string() طريقة.
2. اجعل كل عنصر من عناصر المصفوفة تجزئة، حتى أستطيع أن أقول ذلك a[5][7]['text'] أو a[5][7]['link'].
3. قم بعمل إصدارات مختلفة من المصفوفة، على سبيل المثال. textArray[5][7], linkArray[5][7]

يبدو إنشاء HTML كبداية واستخدام الإصدار النصي فقط فكرة سيئة، حيث يختلف المظهر حسب الاستخدام (على سبيل المثال. 2009-09-14 ضد مو 14 سبتمبر).

أم أنني فقط أطرح السؤال الخطأ؟

Answer 1

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

عادةً ما يُفضل (1)/(2) على (3)، نظرًا لأنها تجعل نسخ عنصر مع بياناته الوصفية أسهل بكثير بشكل عام.عند الفرز مثلا

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

Answer 2

كنصيحة عامة، من الأفضل أن لا تحتوي البيانات على أي معلومات على الإطلاق حول كيفية تمثيل نفسها.

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

ولكن في الحالات التي لا يكون فيها ذلك ممكنًا أو عندما يتعين عليك دمج المعلومتين في بنية بيانات واحدة للتحويل الفعلي، فقد اتبعت هذه القاعدة الأساسية:

لا تكن ذكيًا وافعل ما هو أكثر طبيعية في لغتك!

• في Java وDelphi، كنت أستخدم دائمًا متغير "الكائن المخصص"، لأنه يحصل على مزايا معينة مثل التحقق من وقت الترجمة.
• في PHP، كنت أستخدم التجزئة دائمًا لأنه النمط الأكثر شبهاً بـ PHP.

لقد قمت بـ "الحل 3" في بعض الأحيان، لكنني كنت أندم عليه دائمًا.تميل هذه الهياكل إلى أن تصبح كابوسًا للصيانة، ومن المرجح أن تواجه مشكلات في المزامنة، من وجهة نظر البيانات وأيضًا من وجهة نظر الترميز.

Answer 3

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

على سبيل المثال في Ruby on Rails the Table users يتم التعامل معها من قبل فئة User.يمكنك إنشاء كليهما باستخدام سقالة.

ruby script\generate scaffold user lastname:string link:string joined:date

التاريخ، والمنطقية، والسلسلة، والنص، والعشري، والعدد الصحيح هي أنواع بيانات مميزة هنا.لسوء الحظ، عناوين URL ليست كذلك، لذا لا بد لي من استخدام String للرابط.

يمكنك قراءة المستخدمين من قاعدة البيانات مثل هذا:

@u = User.find(77)       # gives you one object
@list = User.find(:all)  # gives you an array of User-objects

تحتوي سمة كائن المستخدم على الأنواع الصحيحة للتعامل مع التواريخ والأرقام وما إلى ذلك:

إذا كان 100.days.ago <@u.joind ثم ....

يتم تنفيذ المنطق المتأصل في البيانات في فئة المستخدم.

قد يتم عرض قائمة المستخدمين بتنسيق HTML باستخدام طريقة عرض مثل هذه:

  <h1>Listing Users</h1>
  <table>
    <tr>
      <th>Lastname</th>
      <th>Link</th>
      <th>Joined on</th>
    </tr>
  <% @list.each do |user| %>
    <tr>
      <td><%=h user.lastname %></td>
      <td><%= link_to "Homepage", user.link %></td>
      <td><%=h user.joined %></td>
    </tr>
  <% end %>
  </table>

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

يتم عرض/إخراج نفس البيانات مثل السيرة الذاتية عن طريق إنشاء عرض السيرة الذاتية.