Bu basit DataMapper uzatmak için?

4 Cevap php

Birisi şu somut bir örnek türetmek lütfen Can:

http://www.urdalen.com/blog/?p=210

.. O one-to-many ve many-to-many ilişkileri ile başa nasıl gösterir?

Ben bir süre önce yazar gönderilecektir ama hiçbir cevap aldık. Ben onun fikir gibi, ama basit bir tek tablo ilişkilerinin ötesinde bunu uygulamak için nasıl anlamaya olamaz.

Not: Ben bir tam şişmiş ORM kullanmak istemiyorum. Ben elle benim SQL yapıyor gibi. Ama benim app kod tasarımını geliştirmek istiyoruz. Şu anda, her etki alanı nesne statik yöntemlerde sarılmış sorguları tam kendi sınıfı vardır. Onlar sadece skaler, 1d-array (kayıt) veya sorguya bağlı olarak 2d-dizi (kayıt) döndürür.

4 Cevap

Orm'un (ne denir gibi empedans uyumsuzluğu) sorunu ilişkileri ile tam da budur. Bir nesne grafiğinde (In-bellek nesneler), ilişkiler diğer nesnelere göstericisidir. İlişkisel veritabanında, ilişkiler ters; Bu imkansız, iki model arasında basit bir eşleme yapmak için yapar, ve ORM en çok karmaşık neden olmasıdır.

Eğer (bir ORM kaçınarak) veritabanına yakın kalmak istiyorsanız, o zaman uzak soyut ilişkiler için denemek gerekir. Ben datamappers yazmak yolu aşağıdaki gibi bir şeydir:

$car42 = $car_gateway->fetch(42);
$wheels = $wheel_gateway->selectByCar($car42);

ORM şekilde aksine:

$car42 = $car_gateway->fetch(42);
$wheels = $car42->selectWheels();

Bu ağ geçitleri istemci-kodu sonuna kadar demek, ama aynı zamanda çok şeffaf ve veritabanına yakın şeyleri tutar.

Eğer basit ve taşınabilir bir DataMapper ORM arıyorsanız, phpDataMapper bakabilirsiniz. Sadece bağımlılıkları PHP5 ve PDO vardır, ve o çok küçük ve hafiftir. Bir de masa ilişkiler ve diğer bazı çok güzel özelliklerini destekler.

Ben size ilişkileri kullanarak içine bir kez olsun o hızla çok daha karmaşık sağlanan basit bir örnek daha alacak düşünüyorum. Ben size özel bir ORM kullanmak istemiyorum dedi biliyorum, ama gerçekten zaten yazılmış bir şey kullanarak daha iyi olacağını düşünüyorum.

Eğer bir şekilde tablenames saklamak gerekir / ilişkilerin katıldı (ve ben bu sağlanan DataValue / DataMapper 'desen' uyabilecek nasıl emin değilim). Sonra muhtemelen bir şekilde ilişki-ed kayıtları ilk sorgu (ve sonra tekrar ilgili nesneleri içine resultset sıralama) katılmak, ya da ayrı ayrı sorgular kullanarak yoluyla getirilen gerektiğini belirlemek gerekir.

Yine, ben bu ne istediğiniz değil biliyorum, ama bu bağımsız ve MVC içine bütün projeyi zorlamaz gibi php Doctrine öneriyoruz.

Tom'un cevap için tepki göz önüne alındığında, ben Zend Framework gibi bir şey bakmak tavsiye ederim. Onun ORM aşamalarında uygulanabilir bir al ya da bırakın bir mimariye sahiptir.

Benim şimdiki işveren geldi, onlar sadece önceden ayını tamamlamış olmuştu ama bir ya da iki önceki sürümleri ve güncel sürümü altı ay kadar uzun olmuştur gerekiyordu daha gelişme olmuştu aracılığıyla olmuştu bir uygulama vardı. Ancak, kod tabanı karışıklık oldu. Örneğin veritabanı erişimi mantık ve iş mantığı arasında hiçbir soyutlama yoktu. Ve, onlar beni sitesi ileriye, yeni işlevsellik bina mevcut özellikleri uzanan, ve kod mevcut hataları tespit taşımak istedim. Ayrıca, veri giriş ve çıkışlarla ilgili sanitasyon herhangi formunu kullanarak değildi şeyleri zorlaştırmak için.

Ben sorun haline Wade başladı, ben onlar tabii ki tam bir yeniden gitmek için gitmiyorum çünkü ben adımda uygulanabilir soyut kaygılar için bir çözüm gerekir fark etti. Benim ilk yaklaşımı benim için ağır kaldırma yapmak istiyorum özel bir ORM ve DAL yazmak oldu. Bu mevcut kod tabanı üzerinde davetsiz vermedi ve bu yüzden beni mütevazi bir şekilde yeni mimariye uygulamanın tüm bölümlerini taşımak için izin çünkü harika çalıştı.

Ancak, bu yeni yapıya sitemizin kullanıcı alanının büyük bir kısmını taşıdık olan ve (aynı zamanda özel bir ön-uç kontrolör ve mvc uygulanmasını içerir geldi) benim özel çerçeve üzerinde tüm bir uygulama inşa ettikten sonra, ben anahtarlama am Zend Framework (Ben diğer çerçeveler bazıları da bu durumda işe emin değilim ama bu benim seçimim).

Zend Framework anahtarlama Çünkü eski kod tabanının hakkında kesinlikle hiçbir kaygıları var:

  • I can build new models and refactor old models (built on my custom framework) unobtrusively.
  • I can refactor the existing controllers (such as they are) to be wrapped within a class that behaves in a manner consistent with Zend's MVC framework so that it becomes a minor issue to actually begin using Zend's Front-End Controller.
  • Our views are already built in Smarty so I don't have to worry about separating controller and view logic, but I will be able to extend the Zend Framework so that I can render existing templates in Smarty while building new templates in straight PHP.

Temelde, Zend Framework onun yeni kod ve refactored kodu mevcut kod davetsiz gerekmez, çünkü mevcut projeler içinde kullanmak için bir sevinç yapar götürün ya da bırakın bir mimariye sahiptir.