لماذا كل هذا السجل النشط الكراهية ؟ [مغلقة]
https://stackoverflow.com/questions/7864
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
كما تعلم المزيد و المزيد عن OOP, والبدء في تنفيذ مختلف أنماط التصميم ، رجعت إلى الحالات التي يكون فيها الناس على كره السجل النشط.
غالبا ما يقول الناس أنه لا مقياس جيد (نقلا عن تويتر على رئيس الوزراء سبيل المثال) -- ولكن لا أحد في الواقع يفسر لماذا لا مقياس جيدا ؛ و / أو كيفية تحقيق إيجابيات AR دون سلبيات (عبر مشابهة ولكن مختلفة النمط؟)
نأمل أن هذا لن تتحول إلى حرب مقدسة عن أنماط التصميم -- كل ما أريد معرفته هو ****تحديدا**** ما هو الخطأ في السجل النشط.
إذا كان لا مقياس حسنا, لماذا لا ؟
ما هي المشاكل الأخرى التي يحتوي عليها ؟
المحلول
هناك ActiveRecord تصميم نمط و ActiveRecord القضبان ORM المكتبة, و هناك أيضا طن من تدق العرضية على .صافي و لغات أخرى.
هذه كلها أشياء مختلفة.في الغالب أن تتبع نمط تصميم ، ولكن تمديد وتعديل ذلك في العديد من الطرق المختلفة ، وذلك قبل أي شخص يقول "ActiveRecord سيء" فإنه يحتاج إلى أن يكون مؤهل بالقول "التي ActiveRecord هناك أكوام?"
أنا على دراية فقط مع القضبان' ActiveRecord سأحاول معالجة جميع الشكاوى التي أثيرت في سياق استخدامه.
@BlaM
المشكلة التي أراها مع السجلات النشطة ، انه دائما فقط حول طاولة واحدة
كود:
class Person
belongs_to :company
end
people = Person.find(:all, :include => :company )
وهذا يولد مع SQL LEFT JOIN companies on companies.id = person.company_id, و يولد تلقائيا المرتبطة الشركة الأشياء حتى تتمكن من لا people.first.company وأنها لا تحتاج إلى ضرب قاعدة البيانات لأن البيانات الموجودة بالفعل.
@pix0r
المشكلة المتأصلة مع السجل النشط هو أن استعلامات قاعدة البيانات يتم تلقائيا إنشاء و تنفيذ لملء الكائنات وتعديل سجلات قاعدة البيانات
كود:
person = Person.find_by_sql("giant complicated sql query")
هذا هو تثبيط كما انها قبيحة, ولكن الحالات حيث كنت عادي فقط و ببساطة تحتاج إلى كتابة الخام SQL سيكون من السهل القيام به.
@تيم سوليفان
و يمكنك اختيار عدة حالات من هذا النموذج ، فأنت تفعل "حدد * من ..."
كود:
people = Person.find(:all, :select=>'name, id')
هذا فقط حدد اسم معرف أعمدة من قاعدة أخرى 'سمات' في تعيين الأشياء سوف يكون مجرد النيل, إلا إذا قمت يدويا تحديث هذا الكائن ، وهلم جرا.
نصائح أخرى
لقد وجدت دائما أن ActiveRecord هو جيد بالنسبة سريعة الخام التطبيقات المستندة إلى حيث نموذج مسطح نسبيا (كما في الكثير من الطبقة الهرمية).ومع ذلك ، للتطبيقات المعقدة OO الهرمية ، DataMapper هو على الأرجح أفضل حل.في حين ActiveRecord يفترض نسبة 1:1 بين الجداول الخاصة بك والبيانات الخاصة بك كائنات هذا النوع من العلاقة يحصل عملي مع أكثر تعقيدا المجالات.في احجز على أنماط, مارتن فاولر أن ActiveRecord يميل إلى كسر في ظل الظروف حيث النموذج الخاص بك هو معقد إلى حد ما ، ويدل DataMapper كما البديلة.
لقد وجدت أن هذا صحيح في الممارسة العملية.في الحالات حيث لديك الكثير الميراث في المجال الخاص بك, فمن الصعب خريطة الميراث إلى RDBMS من خريطة الجمعيات أو التكوين.
الطريقة التي يمكنني القيام به هو أن يكون "الملك" الكائنات التي يتم الوصول إليها من خلال وحدات التحكم الخاصة بك عن طريق هذه DataMapper (أو "طبقة الخدمة") الطبقات.هذه لا مباشرة مرآة قاعدة البيانات ولكن بمثابة OO تمثيل بعض العالم الحقيقي الكائن.نقول لديك فئة المستخدم في المجال الخاص بك تحتاج إلى مراجع أو مجموعات من الكائنات الأخرى ، تحميلها بالفعل عند استرداد أنه كائن المستخدم.قد تكون البيانات القادمة من العديد من جداول مختلفة ، ActiveRecord نمط يمكن أن تجعل من الصعب حقا.
بدلا من تحميل كائن المستخدم مباشرة و الوصول إلى البيانات باستخدام ActiveRecord نمط API, جهاز تحكم رمز استرداد كائن مستخدم عن طريق استدعاء API من UserMapper.getUser (طريقة) ، على سبيل المثال.هو أن معين هو المسؤول عن تحميل أي الأشياء المرتبطة بها من كل منهما الجداول وإعادة الانتهاء المستخدم "المجال" كائن إلى المتصل.
أساسا أنت فقط إضافة طبقة أخرى من التجريد لجعل رمز أكثر قابلية للإدارة.إذا كان الخاص بك DataMapper الطبقات تحتوي على الخام SQL مخصص ، أو يدعو إلى البيانات طبقة تجريد API ، أو حتى الوصول إلى ActiveRecord نمط أنفسهم, لا يهم حقا أن تحكم التعليمات البرمجية التي يتم تلقي لطيفة ملؤها كائن المستخدم.
على أي حال, هذا هو كيف نفعل ذلك.
أعتقد أن هناك احتمالا مجموعة مختلفة من بين الأسباب لماذا الناس "كره" على ActiveRecord وما هو "خطأ" مع ذلك.
على كره المسألة ، هناك الكثير من السم تجاه أي شيء القضبان ذات الصلة.بقدر ما هو الخطأ في ذلك ، فمن المرجح أنه مثل كل التكنولوجيا و هناك حالات حيث أنه هو خيار جيد و حالات حيث هناك خيارات أفضل.الوضع حيث كنت لا تحصل على الاستفادة من أكثر من الميزات من القضبان ActiveRecord في تجربتي ، حيث قاعدة البيانات بشدة منظم.إذا كنت الوصول إلى البيانات دون المفاتيح الأساسية مع الأشياء التي تنتهك الأول النموذج العادي ، حيث هناك الكثير من الإجراءات المخزنة المطلوبة للوصول إلى البيانات, كنت أفضل حالا باستخدام ما هو أكثر من مجرد SQL المجمع.إذا كانت قاعدة البيانات الخاصة بك هو جيد نسبيا منظم ، ActiveRecord يتيح لك الاستفادة من ذلك.
إضافة إلى موضوع الرد على المعلقين الذين يقولون أن الأمور صعبة في ActiveRecord مع التعليمات البرمجية المتكررة الرد
@سام مكافي نقول لديك فئة المستخدم في المجال الخاص بك تحتاج إلى مراجع أو مجموعات من الكائنات الأخرى ، تحميلها بالفعل عند استرداد أنه كائن المستخدم.قد تكون البيانات القادمة من العديد من جداول مختلفة ، ActiveRecord نمط يمكن أن تجعل من الصعب حقا.
user = User.find(id, :include => ["posts", "comments"])
first_post = user.posts.first
first_comment = user.comments.first
باستخدام تشمل الخيار ، ActiveRecord يتيح لك تجاوز الافتراضي كسول التحميل السلوك.
رحلتي الطويلة في وقت متأخر رد ولا حتى كاملة ، ولكن تفسير جيد لماذا أكره هذا النمط والآراء وحتى بعض المشاعر:
1) نسخة قصيرة:السجل النشط يخلق "طبقة رقيقة"من "ملزمة قوية"بين قاعدة البيانات رمز التطبيق.الذي يحل لا منطقية ولا أيا من المشاكل ، أي مشاكل على الإطلاق.IMHO أنها لا تقدم أي قيمة ، باستثناء بعض نحوي السكر بالنسبة للمبرمج (يمكن استخدام كائن "بناء الجملة" إلى الوصول إلى بعض البيانات الموجودة في قاعدة بيانات علائقية).الجهود الرامية إلى إنشاء بعض الراحة المبرمجين أن (IMHO...) الأفضل أن تستثمر في انخفاض مستوى قاعدة البيانات الوصول إلى أدوات مثلبعض الاختلافات البسيطة, سهل, عادي hash_map get_record( string id_value, string table_name, string id_column_name="id" ) و أساليب مماثلة (بالطبع مفاهيم الأناقة يختلف كثيرا مع اللغة المستخدمة).
2) نسخة طويلة:في أي قاعدة بيانات يحركها المشاريع حيث كان "المفاهيمي السيطرة" من الأشياء, تجنبت ع ، و كانت جيدة.أنا عادة بناء الطبقات المعمارية (لك عاجلا أو آجلا تقسم البرمجيات الخاصة بك في طبقات على الأقل في متوسطة إلى كبيرة الحجم المشاريع):
A1) قاعدة البيانات نفسها, الجداول, العلاقات, حتى بعض المنطق إذا كان DBMS يسمح لها (الخلية أيضا كبروا الآن)
A2) في كثير من الأحيان ، هناك أكثر من مخزن البيانات:نظام الملفات (النقط في قاعدة البيانات ليست دائما جيدة القرار...) ، النظم القديمة (تخيل نفسك "كيف" سيتم الوصول إلى العديد من أصناف ممكن..ولكن هذا ليس نقطة...)
ب) طبقة الوصول إلى قاعدة البيانات (على هذا المستوى ، أداة أساليب المساعدين الوصول بسهولة إلى البيانات في قاعدة البيانات هي موضع ترحيب للغاية ، ولكن ع لا تقدم أي قيمة هنا ، ما عدا بعض نحوي السكر)
ج) تطبيق كائنات طبقة:"كائنات التطبيق" في بعض الأحيان بسيطة الصفوف من جدول في قاعدة البيانات ، ولكن في معظم الأحيان هم مجمع الأشياء على أي حال ، وبعض أعلى المنطق المرفقة ، لذا استثمار الوقت في ع الكائنات في هذا المستوى فقط صراحة لا طائل منه ، مضيعة الثمينة المبرمجون الوقت ، لأن "القيمة الحقيقية" ، "منطق أعلى" من هذه الكائنات يجب أن ينفذ على رأس AR الكائنات ، على أية حال - مع أو بدون AR!وعلى سبيل المثال لماذا كنت تريد أن يكون مجردا من "تسجيل دخول الكائنات"?التطبيق المنطق رمز يكتب لهم ، ولكن يجب أن يكون لديك القدرة على تحديث أو حذف منها ؟ يبدو سخيفا ، App::Log("I am a log message") بعض المقادير أسهل في الاستخدام من le=new LogEntry(); le.time=now(); le.text="I am a log message"; le.Insert();.و على سبيل المثال:باستخدام "تسجيل الدخول كائن" في عرض سجل في التطبيق الخاص بك سوف تعمل 100, 1000 أو حتى 10000 سجل خطوط, ولكن عاجلا أو آجلا سيكون لديك لتحسين أراهن أن في معظم الحالات, سوف فقط استخدام تلك الصغيرة الجميلة SQL SELECT في التطبيق الخاص بك المنطق (وهو تماما يكسر ع فكرة..) بدلا من التفاف الصغيرة بيان جامدة ثابتة ع فكرة إطارات مع الكثير من التعليمات البرمجية التغليف و إخفائه.الوقت الذي يضيع مع كتابة و/أو بناء ع رمز يمكن استثمارها في أكثر ذكي واجهة وقوائم القراءة من تسجيل إدخالات (العديد من, العديد من الطرق, السماء هي الحد).المبرمجون أن يجرؤ على ابتكار الجديد تجريدات لتحقيق تطبيق المنطق أن تناسب المقصود التطبيق ، ليس بغباء إعادة تنفيذ سخيفة أنماط, هذا يبدو جيدا على أول وهلة!
د) تطبيق المنطق - تطبق منطق التفاعل الكائنات وخلق حذف وإدراج(!) تطبيق منطق الكائنات (لا, تلك المهام يجب أن نادرا ما تكون راسية في تطبيق منطق الأشياء نفسها:هل ورقة على مكتبك أقول لك أسماء ومواقع جميع الأوراق الأخرى في مكتبك ؟ ننسى "ثابت" أساليب قائمة الكائنات, هذا سخيف سيئة التسوية التي تم إنشاؤها لجعل الإنسان طريقة التفكير تنسجم مع [بعض-وليس كل-AR-إطار-مثل-]ع التفكير)
هـ) واجهة المستخدم - حسنا, ماذا سوف تكتب في السطور التالية هو جدا جدا جدا الذاتية ، ولكن في تجربتي المشاريع التي بنيت على AR غالبا ما تهمل واجهة المستخدم جزء من تطبيق - كان يضيع الوقت على إنشاء غامضة تجريدات.في النهاية هذه التطبيقات يضيع الكثير من المبرمجون الوقت أشعر التطبيقات من المبرمجون المبرمجون التكنولوجيا ميلا في الداخل والخارج.المبرمجون يشعر جيدة (العمل الشاق أخيرا, كل شيء انتهى و الصحيح ، وفقا لمفهوم على الورق...) ، للعملاء "فقط يجب أن تعلم أن الأمر يحتاج إلى مثل ذلك" لأن هذا "المهنية"..حسنا, آسف, أنا استطرادا ;-)
حسنا, المسلم, هذا كل ما هو ذاتي ، ولكن تجربتي (روبي على القضبان استبعادها ، قد تكون مختلفة و ليس لدي أي خبرة عملية مع هذا النهج).
في دفع المشاريع ، وكثيرا ما سمعت عن الطلب أن تبدأ مع خلق بعض "السجل النشط" الكائنات لبنة في بناء أعلى مستوى تطبيق المنطق.في تجربتي ، واضح في كثير من الأحيان كان نوعا من عذر أن العميل (برنامج dev الشركة في معظم الحالات) لم يكن لديك فكرة جيدة كبير عرض لمحة عامة عن ما المنتج يجب أن تكون في النهاية.هؤلاء العملاء التفكير في الأطر الجامدة ("في المشروع قبل عشر سنوات وهي تعمل بشكل جيد..") ، قد تجسيد كيانات قد تحدد الكيانات العلاقات قد كسر البيانات العلاقات وتحديد الأساسية تطبيق المنطق ، ولكن بعد ذلك توقف و أسلمها لك, و أعتقد أن هذا كل ما تحتاج...فإنها غالبا ما تفتقر إلى استكمال مفهوم تطبيق المنطق ، واجهة المستخدم وسهولة الاستخدام جرا وهلم جرا...أنها تفتقر إلى كبير نظر وأنها تفتقر إلى الحب للحصول على التفاصيل ، ويريدون منك أن تتبع هذا النحو ع من الأشياء ، لأن..لماذا عملت في هذا المشروع منذ سنوات ، فإنه يبقى الناس مشغول صامت ؟ أنا لا أعرف.ولكن "تفاصيل" فصل الرجال عن الأولاد ، أو ..كيف كانت الأصلي الإعلان الشعار ؟ ;-)
بعد العديد من سنوات (عشر سنوات من التنمية النشطة تجربة) كلما العملاء يذكر "نشط سجل نمط" المنبه يرن الجرس.تعلمت أن نحاول الحصول عليها إلى أن من الضروري التصور المرحلة, دعهم يفكرون مرتين ، في محاولة منهم لإظهار التصور الضعف أو مجرد تجنب لهم على الإطلاق إذا كانت غير المدققة (في النهاية, تعرف, الذي لا نعرف حتى الآن ما يريد, ربما يعتقد أنه يعلم ولكن لا, أو يحاول تخريج مفهوم العمل لي مجانا والتكاليف لي العديد من الثمين ساعات, أيام, أسابيع و أشهر من وقتي ، يعيش قصيرة جدا ...).
أخيرا:هذا هو السبب في أنني أكره هذا سخيف "سجل نشط نمط", و أنا و تجنب ذلك قدر الإمكان.
تحرير:حتى أن أسميه هذا أي نمط.فإنه لا يحل أي مشكلة (أنماط لا تهدف إلى إنشاء النحوية السكر).أنه يخلق العديد من المشاكل:جذر كل المشاكل (ذكر في العديد من الإجابات هنا..) هو ، فإنه يخفي حسن البالغ من العمر متطورة وقوية SQL وراء واجهة من أنماط تعريف محدودة للغاية.
هذا النمط محل المرونة النحوية السكر!
تفكر في ذلك, المشكلة التي لا AR حل بالنسبة لك ؟
بعض الرسائل لي الحصول على الخلط.بعض الأجوبة سوف "أورم" مقابل "SQL" أو شيء من هذا القبيل.
الحقيقة هي أن ع هو مجرد تبسيط البرمجة نمط حيث يمكنك الاستفادة من المجال الخاص بك الكائنات إلى كتابة قاعدة البيانات رمز الوصول.
هذه الكائنات عادة الأعمال سمات (خصائص الفول) و بعض السلوك (الأساليب التي عادة ما تعمل على هذه الخصائص).
AR يقول فقط "إضافة بعض طرق هذه المجال الكائنات" إلى قاعدة بيانات المهام ذات الصلة.
و يجب أن أقول من رأيي والخبرة ، أنني لا أحب هذا النمط.
للوهلة الأولى يمكن أن تبدو جيدة جدا.بعض الحديث جافا أدوات مثل الربيع رو يستخدم هذا النمط.
بالنسبة لي, المشكلة الحقيقية هي فقط مع OOP القلق.ع نمط قوات كنت في بعض الطريق لإضافة تبعية من وجوه الخاص بك إلى infraestructure الكائنات.هذه infraestructure الكائنات تدع المجال كائن الاستعلام عن قاعدة البيانات من خلال الأساليب المقترحة من قبل AR.
لقد قلت دائما أن اثنين من طبقات هي المفتاح لنجاح المشروع.طبقة الخدمة (حيث طبيعة المنطق موجود أو يمكن تصديرها من خلال بعض النوع من الاتصال عن بعد تكنولوجيا المعلومات وخدمات الويب ، على سبيل المثال) و طبقة المجال.في رأيي, إذا أضفنا بعض التبعيات (ليس) إلى طبقة مجال الكائنات لحل ع نمط لنا المجال الكائنات سوف يكون من الصعب مشاركة مع غيرها من الطبقات أو (نادرة) تطبيقات خارجية.
الربيع رو تنفيذ AR مثيرة للاهتمام لأنها لا تعتمد على الكائن نفسه ، ولكن في بعض AspectJ الملفات.ولكن في وقت لاحق إذا كنت لا ترغب في العمل مع رو. و أن ريفاكتور المشروع ، ع الطرق سيتم تنفيذها مباشرة في كائنات المجال.
وجهة نظر أخرى.تخيل نحن لا نستخدم قاعدة بيانات علائقية لتخزين الأشياء.تخيل تطبيق متجر لدينا المجال الكائنات في قاعدة بيانات NoSQL أو فقط في ملفات XML ، على سبيل المثال.سوف نقوم بتطبيق الأساليب التي تفعل هذه المهام في المجال الكائنات ؟ أنا لا أعتقد ذلك (على سبيل المثال ، في حالة XM, ونضيف XML ذات تبعيات إلى كائنات المجال...حقا حزين على ما أظن).ثم لماذا علينا أن ننفذ relational DB الأساليب في مجال الكائنات ، كما ع نمط يقول ؟
والحاصل AR نمط يمكن أن يبدو أكثر بساطة و جيد صغيرة وبسيطة التطبيقات.ولكن عندما يكون لدينا معقدة وكبيرة تطبيقات أعتقد الكلاسيكية العمارة الطبقات هو أفضل نهج.
السؤال هو عن النشطة سجل تصميم نمط.لا orm أداة.
السؤال الأصلي هو ذات الكلمات الدلالية مع القضبان يشير إلى تويتر والتي بنيت في روبي على القضبان.على ActiveRecord إطار القضبان هو تنفيذ فاولر سجل نشط نمط تصميم.
الشيء الرئيسي الذي رأيت فيما يتعلق الشكاوى حول السجل النشط هو أنه عند إنشاء نموذج حول طاولة ، يمكنك اختيار عدة حالات من هذا النموذج ، فأنت تفعل "حدد * من ...".هذا على ما يرام بالنسبة تحرير سجل أو عرض سجل, ولكن إذا كنت ترغب في, قول, عرض قائمة المدن لجميع جهات الاتصال في قاعدة البيانات الخاصة بك ، يمكنك أن تفعل "اختر المدينة من ..." وفقط الحصول على المدن.تفعل هذا مع السجل النشط يتطلب أن كنت اختيار جميع الأعمدة ، ولكن فقط باستخدام المدينة.
بالطبع متفاوتة تطبيقات سيتم التعامل مع الأمر بشكل مختلف.ومع ذلك ، فإنه في مسألة واحدة.
الآن, يمكنك الحصول على حول هذا من خلال خلق نموذج جديد من أجل شيء محدد كنت تحاول القيام به ، ولكن بعض الناس يقولون أنه جهد أكثر من فائدة.
لي أحفر السجل النشط.:-)
HTH
أنا أحب الطريقة دون سرعة الصوت لا عمود واحد فقط شيء.
إما
DataBaseTable.GetList(DataBaseTable.Columns.ColumnYouWant)
, أو:
Query q = DataBaseTable.CreateQuery()
.WHERE(DataBaseTable.Columns.ColumnToFilterOn,value);
q.SelectList = DataBaseTable.Columns.ColumnYouWant;
q.Load();
ولكن Linq لا يزال الملك عندما يتعلق الأمر تحميل كسول.
@BlaM:أحيانا justed تنفيذ نشط سجل نتيجة الانضمام.لا يجب دائما أن تكون العلاقة الجدول <--> السجل النشط.لماذا لا "نتيجة الانضمام البيان" <--> النشطة سجل ؟
انا ذاهب الى الحديث عن السجل النشط مثل نمط تصميم, لم أر رور.
بعض المطورين أكره السجل النشط ، لأنها قراءة الكتب الذكية حول كتابة نظيفة ومرتبة رمز هذه الكتب الدول التي سجل نشط ينتهك واحد resposobility مبدأ يخالف DDD قاعدة كائن المجال يجب أن يكون دائم جاهل و العديد من القواعد الأخرى من هذا النوع من الكتب.
الشيء الثاني كائنات المجال في السجل النشط تميل إلى أن تكون 1 إلى 1 مع قاعدة البيانات ، التي قد تعتبر قيدا في نوع من أنظمة (n-tier في الغالب).
هذا مجرد أشياء مجردة ، لم أر روبي على القضبان التنفيذ الفعلي من هذا النمط.
المشكلة التي أراها مع السجلات النشطة ، انه دائما مجرد عن واحد الجدول.لا بأس طالما أنك حقا العمل مع مجرد طاولة واحدة ، ولكن عند العمل مع البيانات في معظم الحالات سوف يكون نوعا من الانضمام إلى مكان ما.
نعم ، الانضمام وعادة ما هو أسوأ من لا تنضم في كل عندما يتعلق الأمر بالأداء, ولكن الانضمام عادة هو أفضل من "وهمية" الانضمام من خلال القراءة الأولى كل طاولة ثم باستخدام المعلومات المكتسبة من قراءة و تصفية الجدول باء.
المشكلة مع ActiveRecord هو أن يستعلم ذلك يولد تلقائيا بالنسبة لك يمكن أن يسبب مشاكل الأداء.
كنت في نهاية المطاف القيام ببعض unintuitive الحيل لتحسين الاستفسارات التي يترك كنت أتساءل إذا كان يمكن أن يكون أكثر الوقت فعالة كتابة الاستعلام باليد في المقام الأول.
على الرغم من أن جميع التعليقات الأخرى فيما يتعلق SQL الأمثل بالتأكيد صالحة ، شكوي الرئيسية مع السجل النشط النمط هو أنه عادة ما يؤدي إلى مقاومة عدم التوافق.أنا أحب حفظ بلدي المجال نظيفة بشكل صحيح مغلفة الذي سجل نشط نمط عادة يدمر كل أمل في القيام.
حاولت العديد من العديد من الأشكال العلاقة.ليس من السهل.وخصوصا عندما كنت لا تستخدم STI.
