Neden henüz model odaklı geliştirme yapmıyoruz? [kapalı]

Model Odaklı Gelişim'e gerçek bir inancım, bence üretkenliği, kaliteyi ve öngörülebilirliği artırma olasılığı var. MetaEdit'e baktığınızda sonuçlar inanılmaz. Hollanda'da Mendix çok hızlı büyüyor ve harika sonuçlar veriyor .

Ayrıca çok fazla sorun olduğunu biliyorum

• jeneratörlerin, şablonların ve çerçevenin sürümlendirilmesi
• model odaklı geliştirme için doğru olmayan projeler (yeterli tekrar değil)
• daha yüksek riskler (ilk proje başarısız olduğunda, daha geleneksel gelişimden daha az sonuç alırsınız)
• vb

Ancak yine de bu sorunlar çözülebilir görünmektedir ve faydalar gereken çabadan daha ağır basmalıdır.

Soru : Model güdümlü kalkınmayı bile dikkate almamanızı sağlayan en büyük sorun olarak neler görüyorsunuz?

Bu cevapları sadece kendi anlayışım için değil, yazmayı planladığım bir dizi dahili makale için de olası bir kaynak olarak kullanmak istiyorum.

Altın çekiç yok. Bir alanda iyi çalışan bir başka alanda oldukça işe yaramaz. Yazılım geliştirmede bazı karmaşıklıklar vardır ve hiçbir sihirli araç onu kaldıramaz.

Kod üretmenin sadece dilin (veya çerçevenin) MDD'yi nispeten anlamsız hale getirecek güçlü soyutlamalara izin verecek kadar yüksek olmadığı durumlarda yararlı olduğu iddia edilebilir.

İlginç soru! İtiraf ediyorum, hayran değilim, ama sonra yeni ortaya koyduğunuz sorunların bazılarına uyan projelerde model odaklı geliştirmeyi birkaç kez kullanmaya çalıştım.

İşte neden listem:

• öğrenme eğrisi - modelleme araçları o kadar hızlı gelişiyor ki, aracı derinden anlayan mühendisleri bulmakta zorlanıyorum. Hala sadece modelleme aracınız kadar iyi olduğunuzu görüyorum. Kuşkusuz, aşağıdaki sorunların çoğu bu sorunu çözebilir - bir aracın çok sınırlayıcı olduğunu düşündüğünüzde, yeterince iyi bilmemeniz mümkündür.
• Çok yapılandırılmış - Şahsen, modelleme aracının anlatmam gereken her şeyi açıklamama izin verecek kadar yapılandırılmış olduğunu bulduğum durumlarda bulundum. Modelin bazı parçalarını aracın dışına çizmeye başladığımda, insanlar bilgileri bulmak için aracın dışına doğru sürüklendikçe işler hızla bozulur.
• Aracı ayarlama maliyeti - Her kod otomatik oluşturmaya çalıştığımda, aracın doğru olduğunu düşündüğümde kodu manuel olarak yeniden çalıştım. Biliyorum, birkaç kez etrafta dolaştıktan sonra bu sorun azalıyor, ama bu ilk birkaç turda hayatta kalmanız gerektiği anlamına geliyor. Genelde bir köstebek patlatmak oynadığımızı hissettim - model oluştur -> kod oluştur -> kod düzelt -> model güncelleme -> model düzelt, durula ve tekrarla.
• Model Konfigürasyon Yönetimi - Model projenin büyük bölümlerini açıkladığından, bir düzeyde model CM yerleşik koddan daha fazla kesişen olacaktır. Modelleme dosyalarını bölümlere ayırmak kendi başına bir sanattır - yanlış yapın ve genellikle geliştiricinin çıkmaza girmesi veya insanlar vazgeçip koda gittikçe güncel olmayan modellerle sonuçlanırsınız.
• piyasaya sürülme zamanı - Çalışan yazılım ihtiyacının acil olduğu bir durumda kesin sorunlar yaşadım. Proje ve ekip yeterince küçükse, zaman kodlama ve test için harcanabilecek bir modelleme aracında zaman kaybetmek için bir neden göremiyorum. Her proje böyle bir yatırım gerektirecek kadar büyük değildir.
• Başarısızlık maliyeti - modelleme araçlarından kaçan projeler gördüğümde, yüksek başarısızlık maliyeti nedeniyle - araçları kullanmak için her geliştiricinin dahil olması gerekir. Bu, eğitime büyük bir yatırım ve öğrenmeye eller ve birisi modeli kötü bir şekilde kurmuşsa çok maliyetli bir hata. Deneyimlerim, modeli doğru hale getirmek için iki veya üç sürüm alabileceğidir - bu yüzden birçok proje faydaları gerçekleştirmek için yeterince uzun modelleme hatalarından kurtulamıyor.

Zaten alıntılanmıştır, ancak No Silver Bullet bu noktaya oldukça iyi hitap eder:

Bir yazılım varlığının özü, birbirine kenetlenen kavramların bir yapısıdır: veri setleri, veri öğeleri arasındaki ilişkiler, algoritmalar ve fonksiyonların çağrılması. Bu öz, böyle bir kavramsal yapının birçok farklı temsil altında aynı olması bakımından soyuttur. Yine de son derece hassas ve zengin detaylandırılmıştır.

Yazılım geliştirmenin zor kısmının, onu temsil etme ve temsilin doğruluğunu test etme çabası değil, bu kavramsal yapının özellikleri, tasarımı ve test edilmesi olduğuna inanıyorum. Emin olmak için hala sözdizimi hataları yapıyoruz; ancak çoğu sistemdeki kavramsal hatalarla karşılaştırıldığında bulanıktır.

Bu doğruysa, yazılım oluşturmak her zaman zor olacaktır. Doğal olarak gümüş mermi yoktur.

Daha sonra Brooks, "otomatik programlama" kavramı hakkında şunları belirtiyor:

Neredeyse 40 yıldır, insanlar "otomatik programlama" ya da problem spesifikasyonlarının bir ifadesinden bir problemi çözmek için bir programın oluşturulması hakkında tahmin ve yazılar yazıyorlar. Bugün bazıları bu teknolojinin bir sonraki atılımı sağlamasını bekliyormuş gibi yazıyor.

Parnas, bu terimin anlamsal içerik için değil, cazibe için kullanıldığını, "Kısacası, otomatik programlamanın, programcı için şu anda mevcut olandan daha yüksek seviyeli bir dilde programlama için her zaman bir örtmece olduğunu " belirtmektedir.

Özünde, çoğu durumda, belirtimi verilmesi gereken sorun değil, çözüm yöntemi olduğunu savunuyor.

Temel olarak, MDD'nin daha önce mevcut olandan daha yüksek seviyeli bir dille programlama için başka bir örtmece olduğunu iddia ediyorum.

Bu, daha üst düzey bir dilde programlamanın yardımcı olamayacağı anlamına gelmez - aslında çoğu zaman olabilir. Ancak sorunun özü aynı kalır: bir araç ne kadar büyük veya ne kadar büyük bir dil kullanıyor olursanız olun , günün sonunda tüm sorunları düşünmeniz ve sorunları çözmeniz gerekir. Herhangi bir araç veya herhangi bir işlemin yapabileceği en iyi şey, "fuzz" ı kaldırmaktır, böylece Brooks'un dediği gibi " bu kavramsal yapının özellikleri , tasarımı ve testi " ne odaklanabilirsiniz .

Çünkü tüm programlama, MDD araçlarının beklediği nesne yönelimli değildir. UML'nin kendisi nesnelerin varsayımına dayanır. Tabii ki fonksiyonları modellemek için dizi diyagramlarını kullanabilirsiniz, ancak çoğu zaman bu beceriksizdir.

Çünkü benim gibi TDD'den MDD'den daha fazla ilerleme ve sonuç alan programcılar var.

Çünkü Modelleme! = Programlama.

Çünkü maliyet / fayda maliyet tarafında çok yüksekti ve fayda tarafında yeterli değildi. MDD'ye en son baktığımdan beri bu muhtemelen değişti, o zamanlar orta derecede MDD yapabilen bir araç için> 6000 $ / koltuk (USD) ödemeniz gerekecektir.

Çünkü kodu üretmek için bir işlevi yeterince tanımlayan bir model artık model olarak kullanışlı değildir.

Çünkü benim gibi modelleri sadece yüksek seviyede kullanan ve daha sonra detayları kodla çalıştıran programcılar var. Kodlamada modelleme yazılımında olduğundan farklı şeyler görürsünüz.

Şahsen MDD yapmamamın nedenlerinden bazıları bunlar. Buna maruz kaldım, ancak hiçbir şey beni dönüştürmekten alamadı. Belki de çok eski bir okulum. Belki de çok yeni bir okulum (her neyse). Sadece kendisi için ödeme yapabildiğim bir araç değil.

Microsoft / Apple / Google zorlamıyor :)

Ne tür bir gelişmenin popülerleştiği araçlar, destekleyici ve evanjelizm ile çok ilgilidir. Büyük bir destekçiye sahip olmadan bir şeyden kurtulmak çok zor (belki de istisna olmak için raylarda Ruby ama Java / C # / Python ile karşılaştırıldığında hala küçük)

Tüm bu modelleme araçlarını etkileyen basit bir yasa nedeniyle, bilirsiniz, CASE, UML ve benzeri:

Bir programcı ile kodu arasında geçiş yapmak çok masraflıdır.

Bunu yaparsanız, uygun bir derleyici / yorumlayıcı oluşturmanız gerekir, kod üreteçleri programcıya korkunç iş akışı ve korkunç geri bildirim (hata mesajları ve benzeri) ile sonuçlanır.

Etki Alanına Dayalı Tasarım'ın en önemli görüşlerinden biri, Modellerin kodun dışında bir şeyde değil kodda olması gerektiğidir.

Sonuçta soru şu: Modelleriniz neden koda uymuyor? Gömülü geliştirme yapıyorsanız ve C ile sıkışıp kalıyorsanız veya farklı platformlar için kod üretmeniz gerekiyorsa, kod oluşturma maliyete değer olabilir. Diğer herkes için, daha güçlü bir programlama dili ve daha iyi kod tasarımı genellikle kodu koddan başka bir şeyde tasarlamaktan daha iyidir.

• Çok az fayda için devasa bir güçlük gibi görünüyor.
• Her zaman kenar durumlarda ve garip şeylerle dinking yapıyorum, sihirli şeyler asla gerçekten işe yaramaz gibi görünüyor.
• OO gümüş bir kurşun değil; OO üzerine yazılım üreten bir metodolojinin bloke edilmesi onu gümüş yapmaz.

Ama genel olarak girişimci çözümlerden hoşlanmıyorum.

Tartışmayı yaptım ve MDA yapmak isterdim, ama en büyük dezavantajı şimdilik araç desteği. Ben "Çalışma Zamanı Modeli değerlendirme" olarak adlandırmak gibi bir MDA türevi kullanıyorum, ama daha sonra.

MDA'nın dezavantajları, bildiğim gibi:

• Yeniden Düzenleme Desteği Eksik: Tahmin edelim ki benim veri modelimin varlıkları MDA ile modellemek istiyorum. Modelim varsa, diyelim ki, bir UML diyagramı varsa ve bunu değiştirirsem, kodumun hiçbiri onunla değişmez (en azından oluşturulan sınıflar) ve hala daha iyi adlandırılmış özniteliklere sahip çalışan bir uygulamaya sahip olmak yerine, birçok hata el ile düzeltmek zorunda.
• Hata ayıklama desteği eksik: Genellikle modelden koda çeviriler bazı dönüştürme dilleri elinizin altındadır. Bu genellikle sorun olmaz, ancak hata ayıkladığımızda, ürettiğimiz koddan endişe etmemeliyiz ve bir hata ayıklayıcı dönüşüm modeline adım atmalıdır. Bunun yerine üretilen koda adım atar ve hepimizin bildiği gibi, dönüşümler üretilen koda değil iyi görünmelidir. Tamam, güzel yazdırabiliriz, ancak en uygun dünyada üretilen kod bir derleyici artefaktıdır ve asla bir hata ayıklama oturumu için bir editörde açılmamalıdır (onunla yaşayabilirim ve bu argüman biraz teorik olarak, ancak MDA'ya karşı bir sebeptir)
• Kodlanmış modeller kolaydır: Diğer örneklerde, Model bazı etki alanı yönlerini modelleyebilir ve daha sonra kod halinde derlenebilir. Evet, MDA, ancak çoğu MDA modeli, çalışma zamanında kolayca işlenebilen sadece gelişmiş yapılandırma dosyalarıdır.
• Dönüşümleri test etmek zor: Uzmanlaşmış bir IDE'de dönüşümler kullanıyorsanız, IDE'ler "derleyicisi" tarafından yapılır. Ancak dönüşümler, uygulamanın kodunun bir parçası olarak görülmelidir ve bu nedenle uygulamanın test ve kod kapsamı gereksinimlerine de uymalıdır.

Şu anda tercih ettiğim "Çalışma Zamanı Modeli Değerlendirmesi" dir (birisi bunun için kabul edilen bir ad biliyorsa lütfen beni aydınlatın). Varlıklarım sıradan Java sınıflarında saklanıyor ve "modellemek" için ihtiyacım olan her şey uygulamanın başında okuduğum ek açıklamalarla yapılıyor. Dönüştürmeye gerek yok, meta modelimi doğru hale getirmek biraz zor oldu.

Diğer her şey hiyerarşik veriler için özellik dosyaları veya XML ile yapılır. Bir modeliniz varsa, her zaman hiyerarşiktir, bu nedenle modelleyebileceğiniz, XML ile de ifade edemeyeceğiniz hiçbir şey yoktur. Ayrıca, muhtemelen yazmanız gereken özel bir model düzenleyiciye ihtiyacınız varsa, uygulamanın çalışma zamanında bile çalışan ve uygulamayı modelleyebileceğiniz her şeyden daha yapılandırılabilir hale getiren bir düzenleyici de oluşturabilirsiniz.

İnsanların neden MDD yapmadığını açıklamak için Fred Brooks'un Gümüş Bullet'i kullanan çoğu insanın Brooks'un yaptığı noktayı kaçırdığını hissediyorum. Elbette, nihai sonuç, yazılım geliştirmedeki gerçek, içsel karmaşıklığın asla ortadan kalkmayacağı ve böylece MDD'nin bunu çözmeyeceğidir.

Ancak Brooks'un bu içsel karmaşıklığı bile tartışmasının bir nedeni, onu tipik olarak diller, kütüphaneler ve araçlarla savaşmak için harcadığımız büyük zamanla karşılaştırmak, yani çözmeye çalıştığımız sorunun içsel karmaşıklığıyla uğraşmamaktır. MDD tam da bu noktada parlıyor: tüm bulanıklığı kesmek ve eldeki gerçek karmaşıklıkla başa çıkmak için özel bir dil, model veya başka bir biçimcilik yaratmak.

Bu açıdan, No Silver Bullet MDD'ye yatırım yapmak için mükemmel bir neden. Yani, MDD'nin benimsenmesini engellediğine inandığım sorun olmasaydı: çözmeye çalıştığınız sorunun tamamen kendine özgü karmaşıklığına odaklanmanızı sağlayan model odaklı bir ortamın gerçek gelişimi, sorunu doğrudan genel amaçlı bir dilde çözmek. Çoğunlukla mevcut MDD takımları oldukça karmaşıktır.

Bunu şöyle karşılaştırın: C'de bir program yazmak, C derleyicisi yazmaktan çok daha kolaydır. Sadece bir problemi çözmek ve genel amaçlı bir dilde kruvazörle uğraşmak yerine, diğer geliştiriciler için bir MDD ortamı yapmak, temel olarak problem alanındaki kruvazörle ilgili tüm olası problemleri çözen bir program yazmanızı gerektirir. Bu oldukça zor.

Bildiğim kadarıyla MDE ve MDA, yerleşik denetleyici geliştiricisinin ihtiyaçlarını yeterince karşılamıyor. Modeller kesinlikle bir sistemi tanımlamak için kullanılabilir, ancak gömülü geliştiricinin en iyi, hatta doğru kaynak kodunu sunmak için modele güvenmeye hazır olduğunu düşünmüyorum.

Eclipse için, geliştiricinin Java kodu oluşturmak / güncellemek için modeli veya modeli oluşturmak / güncellemek için Java kodunu kullanmasına izin veren bir dizi eklenti vardır. Bu kullanışlı bir araç gibi görünüyor. Ne yazık ki, tüm gelişimim ANSI / ISO C'de yapıldı ve farkında olduğum, aynı şeyi yapmama izin verecek eklentiler yok.

Ayrıca, bir geliştirici, modele, kodu olay güdümlü bir HSM veya başka bir tasarım deseni olarak başka bir tasarım deseni (veya anti-desen) üzerinde uygulama talimatını nasıl verebilir? Kod bilinmeyen bir tasarım deseni kullanacak şekilde manuel olarak güncellenirse, model bunu doğru bir şekilde tasvir edebilir mi?

Bir modele uymayan işlevleri nasıl uygularsınız?

Kısa cevap… çünkü sürülen model genellikle kod üretimi ile ilgilidir ve kod kırılgandır; İhtiyacımız olan şey kodların ortadan kaldırılması ve modelin yönlendirilmesinin kesinlikle yoludur.

Bazıları, altın çekiç olmadığını ve yazılım geliştirmenin doğası gereği karmaşık olduğunu savunarak soruyu reddetti.

Onlara altın bir çekiç olmadığı konusunda tamamen katılıyorum ama modelin altın çekiç veya gümüş mermi arayışı olduğunu düşünmüyorum!

Karmaşıklıkla daha ileri gitmek istiyorum; organik veya doğal karmaşıklık dediğim iki tür karmaşıklık var, karmaşıklık iş ve süreçlerinin doğasında var ama aynı zamanda törensel karmaşıklık da var.

Her gün talimatlarla sistem talimatına sızan karmaşıklık. Tören karmaşıklığı - gereksiz karmaşıklık - temelde teknik kodun iş odaklı kodla kontrolsüz bir şekilde yönetilmesinden, aynı zamanda sistemdeki yapı ve tekdüzelik eksikliğinden ortaya çıkar.

Bugün bilgi sistemlerinin gelişimini engelleyen ve başarısızlığa ve bele neden olan karmaşıklığın tamamı törensel karmaşıklıktır; ortadan kaldırılabilecek karmaşıklık.

Tören karmaşıklığı atık, kodun neden olduğu atık, daha az değer, olumsuz değişim, değişmez kod; katı minimuma indirilmesi gereken kod.

Bu nasıl yapılır? Kolay! Sadece yazmayın ve ilk etapta oluşturmayın!

Gerekli, değişmez teknik kod; okuma / yazma, görüntüleme, iletişim için kullanılan kod… Verilerin mantıksal yapısını tanımlayarak modellerin girdiği yer budur - İlişkisel bir şekilde eklerim - modeller standart okuma / yazma, görüntüleme ve iletişimin genel olarak işlenmesini sağlayabilir veri.

Tıpkı bir işletim sistemi gibi, kullandığınız her proje için yeniden yazmazsınız. Yani ihtiyaç duyulan şey, bir model verilen yazılımın değişmez yönlerini ele alan teknik bir motordur. Buna AaaS (Hizmet Olarak Mimari) motoru diyorum.

Gereksiz koda gelince, bu gereksiz bir koddur, bu yüzden de yazılmamış olarak bırakabilir.

Bu da bize yazılması gereken gerekli, iş odaklı kod, tasarlanması gereken iş odaklı veri ve tasarlanması ve hayal edilmesi gereken gerekli kullanıcı arayüzü ve deneyimi sağlar.

Hassas kodu ortadan kaldırarak Mimari olarak Hizmet olarak, kodlamadan çok modelleme ve tasarıma dayalı yazılım geliştirme için yeni bir paradigma benimseyebiliriz.

Çeşitli nedenlerin olduğuna inanıyorum ama biri MDD'nin üniversitelerin müfredatında olmadığından emin. Tipik olarak en yakın modellemeyi öğreten bir derstir ve orada modeller eskiz olarak kalır (kontrol yok, kod oluşturma, model düzeyinde hata ayıklama). Bu “modelleme” kursu genellikle UML'yi tanıtır ve öğrenciler, oluşturulan modellerin değeri düşük olduğunda neden bu kadar büyük ve karmaşık bir notasyonu öğreneceklerini düşünmezler.

Bunu, öğrencilerin oldukça farklı bir deneyim yaşadığı gömülü donanım geliştiricileri veya kontrol mühendisleri gibi diğer mühendislik alanlarıyla karşılaştırın. Simulink veya Labview gibi araçlarla öğrenciler bir model çizebilir ve daha sonra size kodu üretebilir veya en azından simülasyonda çalıştırabilirsiniz.

Geçmişte üniversiteler derleyiciler ve ayrıştırıcılar öğretti, ancak şimdi jeneratörlerin nasıl üretileceğini, DSL'lerin nasıl uygulanacağını vb.

Model Odaklı Geliştirme mantıklı değildir, çünkü bu, yukarıdan aşağıya kodlama yaklaşımı modelidir. Sadece bir modelden tam çalışan uygulama oluşturmak imkansızdır ve bu nedenle MDD işe yaramaz !!

Yaptığım şey UML'i sadece uygulamamın iskeletini oluşturmak için daha yüksek soyutlama düzeyinde kullanmak. Demek istediğim Paketler, sınıflar vs oluşturmak ... sonra hemen Java dilinde kodlamaya başlayın.

2004'te ilk kez modellemeye başladığımda Togethersoft, Omondo gibi araçlarla canlı senkronizasyonun gerçekten yararlı olduğunu gördüm. Omondo tarafından yakın zamanda Java, model ve veritabanı kimliği arasında bir tür eşleme olan yeni bir aşama ortaya çıktı. Gerçekten güçlü ve projelerimde iyi çalışıyor.

UML diyagramlarım şimdi projemi hızlandırmama yardımcı oluyor ve artık işe yaramaz :-)

MDD, iyi bir modelin olmadığı ve piyasaya ilk tahmin edilemeyen veya neredeyse kırılmış kısmi çözümün en fazla mermeri kazanabileceği durumlarda bir dezavantaj olan geliştirme sürecine bir adım daha ekler.

Yürütülebilir iş süreci modellerine sahip olmak kutsal bir kâse olmuştur. Teorik olarak bunun için programcılara ihtiyacınız olmayacaktı. Uygulama, MDE ile, gerçek modeli çalıştırmanın kod yazmak kadar karmaşık olduğunu göstermektedir.

Deneyimli geliştirici için UML'den oluşturulan sınıfları doldurmanın, örneğin ExecutableUML ile uğraşmaktan çok daha kolay olacağını söyleyebilirim. Öte yandan, ExecutableUML için önemli miktarda bilgisayar bilimi bilgisine ihtiyacınız vardır, bu yüzden bunu kendi başına oluşturan işletme yöneticisine güvenemezsiniz. Teoride sadece hazır blokları (sınıfları) birleştirirdi, ama aslında sorunlara neden olan "tutkal".

Ayrıca, MDE'nin kullanışlılığı, çok sayıda bileşen yeniden kullanımı olan sistemlerle sınırlıdır.

MBSE - Model Tabanlı Yazılım Mühendisliği daha uygun bir terimdir.

MBSE, yürürlükte olan çeşitli araçların sayısını ortaya koyarken, farklı bir proje iş akışı gerektirir. DSML'nin (alana özgü modelleme dili) paydaşlarla inceleme gereksinimlerini etkili bir şekilde iletmek için gereken soyutlama düzeyinde olması gerekir. Ardından, sonunda kod üretmek için modeli sürekli artan iyileştirme düzeyleriyle dönüştürmeniz gerekir.

DSML ve dönüşüm / üretim süreçlerini tam ve doğru bir şekilde uyguladığınızda, eser üretimi çok düşük maliyetle gelir. Ancak hata ayıklanan takım aşamasına ulaşana kadar çok acı vericidir.

MDD'nin başarı öykülerinin çoğu, yerleşik takımlar kullanılarak bir dizi benzer ürünün oluşturulduğu Ürün Hattı Mühendisliği (PLE) alanındadır. Elbette, Java kod üreticilerinin çoğu MDD'nin gerçekten basitleştirilmiş versiyonlarıdır. Bazı XML girişleri ve oluşturulan kod çıkışları.

Sen yazdın:

Ayrıca bir çok sorun olduğunu biliyorum ... sadece model odaklı geliştirme için doğru olmayan projeler (yeterli tekrar değil)

Kodunuz tekrarlanıyorsa, ya kötü bir programlama dili seçtiniz ya da kötü bir şekilde kullanıyorsunuz. Daha iyi dillerle tekrarlamaya gerek yoktur. Ruby Active Record kütüphanesini düşünün. Veritabanı tabloları geçişler yazılarak oluşturulur. Şema tanımının başka herhangi bir yerde tekrarlanmasına gerek yoktur. Tablo sütunlarına karşılık gelen veri üyelerine sahip bir sınıf tanımlamanız gerekmez. Tek bir kod satırı, bir sınıfı bir tabloya bağlar.

Model güdümlü gelişimi zayıf programlama dilleri için karmaşık ve verimsiz bir çözüm olarak görüyorum.