ActiveRecord modeli, SOLID tasarım ilkelerini takip ediyor / teşvik ediyor mu?

Ruby on Rails'den ünlü yapılan ActiveRecord modelinin SOLID tasarım ilkelerinin kullanımını teşvik edip etmemesi ile ilgileniyorum .

Örneğin, ActiveRecord nesnelerinin hem Etki Alanı Mantığı hem de Tek Sorumluluk ihlali olan kalıcılık mantığı içerdiği anlaşılıyor.

ActiveRecord'da bazı geçerli eleştiriler var. Her zamanki gibi, Bob Amca tam olarak özetliyor :

Aktif Kayıt ile ilgili problemim, bu iki farklı programlama tarzı hakkında kafa karışıklığı yaratması. Bir veritabanı tablosu bir veri yapısıdır. Verileri açığa çıkardı ve hiçbir davranışı olmadı. Ancak Aktif Kayıt bir nesne gibi görünüyor. “Gizli” veri ve açık davranışa sahiptir. Veriler aslında gizli olmadığı için “gizli” kelimesini tırnak içine aldım. Hemen hemen tüm ActiveRecord türevleri, veritabanı sütunlarını erişimciler ve mutasyonlar yoluyla verir. Aslında, Aktif Kayıt veri yapısı gibi kullanılmak içindir.

Öte yandan, birçok kişi, iş kuralı yöntemlerini Aktif Kayıt sınıflarına koymuş; Bu onları nesneler gibi görünmesini sağlar. Bu bir ikileme yol açar. Hattın hangi tarafında Aktif Kayıt gerçekten düşüyor? Bu bir nesne mi? Yoksa veri yapısı mı?

Vikipedi, test edilebilirlik konusundaki eleştiriyi özetliyor :

OOP'de kapsülleme kavramı genellikle endişelerin ayrılması kavramıyla çelişmektedir. Genel olarak konuşursak, endişelerin ayrılmasını destekleyen modeller izole edilmiş birim testlerine daha uygun olurken, kapsülleme tercih eden kalıpların API kullanımı daha kolaydır. Aktif Kayıt, veritabanı olmadan yapılan testlerin oldukça zor olduğu noktaya enkapsülasyonu desteklemektedir.

Özellikle Ruby on Rails'in uygulanmasında Gavin King şöyle yazıyor :

Bu noktada, çoğu geliştirici düşünür, tamam, peki bir şirketin koduma bakarak hangi özelliklere sahip olduğunu nasıl bilebilirim? IDE'm onları nasıl otomatik olarak tamamlayabilir? Tabii ki, Rails millet bu soruya hızlı bir cevap var Oh, sadece veritabanı istemcinizi ateşleyin ve veritabanına bakın! Ardından, ActiveRecord'un otomajik büyük harf ve çoğullama kurallarını / kusursuz / bildiğinizi varsayarak , kendi Şirket sınıfınızın niteliklerinin adlarını tahmin edebilecek ve bunları manuel olarak yazabileceksiniz.

Ayrıca Ruby on Rails uygulamasında John Januszczak şöyle yazıyor :

SORUN # 1: STATİK YÖNTEMLER

...

Bazıları Statik yöntemlerin kullanılmasının sadece prosedürel programlamaya dayandığını ve bu nedenle zayıf Nesneye Yönelik tasarım olduğunu söyler. Diğerleri statik yöntemlerin test edilebilirlik için ölüm olduğunu söyler.

SORUN # 2: KÜRESEL YAPILANDIRMA AYARLARI

...

Bu nedenle, örneğimde Account sınıfına ve buna ek olarak Account örneklerine bağımlılık enjeksiyonu yoktur . Hepimizin bilmesi gerektiği gibi, şeyleri aramak çok, çok kötü!

ActiveRecord ve ORM'nin neden genel bir anti-model olarak kabul edildiğine dair birkaç kaynak daha:

• Raylar Activerecord'un StackOverflow'ta etki alanı modeli ayrıştırılması ,
• ORM bir anti-paterndir
• ActiveRecord ile Kirli İlişkiler
• Sayı 23: Ruby'nin Uygulanmasında Katı Tasarım İlkeleri

ActiveRecord her zaman son derece yararlı bir anti-patern gibi hissettim , ancak SRP'ye ve ek olarak bağımlılık inversiyonu ilkesine aykırı olduğuna ek olarak katılıyorum.

(ActiveRecord sınıfının bağımlılık enjeksiyonu için herhangi bir olasılık olmadan uygulandığını farz ediyorum).

Kişisel deneyimlerime göre, ActiveRecord modelinin birim testleri yazmak için büyük bir engel haline geldiğini söyleyebilirim. Kalıcılık katmanının ve iş mantığının tek bir "ActiveRecord sınıfında" birleştirilmesi, birim testleri yazmayı imkansız kılar (ilk önce yeniden değerlendirmediyseniz). Bu nedenle, tek seçenek entegrasyon testleri yazmaktır; ve bu birim testleri kadar etkili değildir. Özellikle çok fazla ActiveRecord sınıfı olan bir projeyi devralacaksanız, bu önemli bir sorun haline gelir; bakımı zor olan oldukça karmaşık entegrasyon testlerine neden olur.

Böylece, ActiveRecord SRP'ye karşı oldukça fazla gelir ve bazı bakım baş ağrıları yaratır; birim testleri yazma gücünü ortadan kaldırıyor gibi görünüyor.