Veritabanıyla ilgili yöntemler tasarlamak, hangisini döndürmek daha iyidir: true / false veya row etkilenmiş mi?

Bir veritabanında (ekleme, güncelleme ve silme) bazı veri değiştirme gerçekleştirmek için bazı yöntemler var. ORM Ben yöntemin bu tip dönüş satır etkilenen int değerleri kullanıyorum. İşlemin başarı / başarısızlık durumunu belirtmek için "yöntemim" için ne döndürmeliyim?

Aşağıdaki kodu döndüren kodu düşünün int:

A.1

public int myLowerLevelMethod(int id) {
    ...
    int affectedRows = myOrm.deleteById(id)
    ...

    return affectedRows;
}

Sonra kullanım:

A.2

public void myOtherMethod() {
    ...
    int affectedRows = myLowerLevelMethod(id)

    if(affectedRows > 0) {
        // Success
    } else {
        // Fail
    }
}

Boolean kullanarak karşılaştırın:

B.1

public boolean myLowerLevelMethod(int id) {
    ...
    int affectedRows = myOrm.deleteById(id)
    ...

    return affectedRows > 0;
}

Sonra kullanım:

B.2

public void myOtherMethod() {
    ...
    boolean isSuccess = myLowerLevelMethod(id)

    if(isSuccess) {
        // Success
    } else {
        // Fail
    }
}

Hangisi (A veya B) daha iyi? Veya her birinin artıları / eksileri?

Başka bir seçenek de temel türler yerine bir sonuç nesnesi döndürmektir. Örneğin:

OperationResult deleteResult = myOrm.deleteById(id);

if (deleteResult.isSuccess()) {
    // ....
}

Bununla, herhangi bir nedenden dolayı etkilenen satır sayısını döndürmeniz gerekirse, OperationResult'a bir yöntem ekleyebilirsiniz:

if (deleteResult.isSuccess()) {
    System.out.println("rows deleted: " + deleteResult.rowsAffected() );
}

Bu tasarım, mevcut kodu değiştirmeden sisteminizin büyümesine ve yeni işlevsellik (etkilenen satırları bilerek) içermesine olanak tanır.

Etkilenen satırların sayısını döndürmek daha iyidir çünkü işlemin nasıl devam ettiği hakkında ek bilgi verir.

Hiçbir programcı sizi suçlayamaz çünkü operasyon sırasında bazı değişiklikler olup olmadığını kontrol etmek için bunu yazmak zorundadır:

if(affectedRows > 0) {
    // success
} else {
    // fail
}

ancak etkilenen satırların sayısını bilmek zorunda kaldıklarında sizi suçlayacaklar ve bu sayıyı elde etmek için bir yöntem olmadığını anlayacaklar.

BTW: "başarısızlık" ile sözdizimsel bir sorgu hatası anlamına gelirse (bu durumda etkilenen satır sayısı açıkça 0 ise), istisnayı atmak daha uygun olacaktır.

Ben hiçbirini tavsiye etmem. Bunun yerine, başarı hakkında hiçbir şey döndürmeyin (geçersiz) ve başarısızlığa bir istisna atın.

Bu, belirli sınıf üyelerini özel olarak bildirmeyi tercih ettiğim sebepten dolayıdır. Ayrıca işlevin kullanımını kolaylaştırır. Daha operasyonel bağlam her zaman daha iyi anlamına gelmez, ama kesinlikle daha karmaşık demektir. Ne kadar az söz verirseniz, o kadar soyutlaşırsınız, müşterinin anlaması o kadar kolay olur ve bunu nasıl uygulayacağınız konusunda daha fazla özgürlüğe sahip olursunuz.

Soru, başarının / hatanın nasıl gösterileceğidir. Bu durumda, bir istisna atarak başarısızlığa işaret etmek ve başarıya hiçbir şey döndürmemek yeterlidir. Neden kullanıcının gereksiniminden fazlasını sağlamam gerekiyor?

Arızalar / istisnai durumlar olabilir ve onlarla başa çıkmanız gerekir. İster bunu yapmak için dene / yakala, ister dönüş kodlarını inceleyin, tarz / kişisel tercih meselesidir. Deneme / yakalamanın arkasındaki fikirler şunlardır: normal akışı istisnai akıştan ayırın ve istisnaların en uygun şekilde işlenebilecekleri katmana kadar kabarmasına izin verin. Yani, birçok kişinin belirttiği gibi, başarısızlığın gerçekten istisnai olup olmamasına bağlıdır.

"Bu bundan daha mı iyi?" iki alternatif aynı şeyi yapmadığında yararlı bir soru değildir.

Etkilenen satır sayısını bilmeniz gerekiyorsa , A sürümünü kullanmanız gerekir. Gerekmiyorsa, B sürümünü kullanabilirsiniz - ancak daha az kod yazma çabası açısından kazanabileceğiniz herhangi bir avantaj zaten gitti her iki sürümü de çevrimiçi bir foruma gönderme sorununu yaşadınız

Demek istediğim: hangi çözümün daha iyi olduğu, tamamen bu uygulama için gereksinimlerinizin ne olduğuna bağlıdır ve bu koşulları bizden çok daha iyi bilirsiniz. Genel olarak daha iyi olan , endüstri çapında, kullanımı güvenli, en iyi uygulama, ateşlenmeyecek bir seçenek yoktur ; bunu kendiniz düşünmelisiniz. Ve bu kadar kolay revize edilen bir karar için, düşünmek için o kadar çok zaman harcamanıza gerek yok.

Sürdürülebilir yazılım tasarımında en önemli ilkelerden ikisi KISS ve YAGNI'dır .

• ÖPÜCÜK : Basit Tut, Aptal
• YAGNI : Buna ihtiyacın olmayacak

Neredeyse hiç hemen gerekmez mantık koymak için iyi bir fikirdir şu anda . Diğer birçok insan arasında, Jeff Atwood (StackExchange'in kurucu ortağı) bunu yazdı ve benim deneyimime göre o ve bu kavramların diğer taraftarları tamamen haklı.

Bir programa eklediğiniz herhangi bir karmaşıklığın maliyeti, uzun bir süre boyunca ödenir. Programın okunması zorlaşır, değiştirilmesi daha karmaşık hale gelir ve hataların içeri girmesi daha kolay hale gelir. "Her ihtimale karşı" bir şeyler ekleme tuzağına düşmeyin. Bu yanlış bir güvenlik duygusu.

İlk seferde nadiren herhangi bir kodu alacaksınız. Değişiklikler kaçınılmazdır; gelecekteki beklenmedik durumlara karşı savunmacı bir şekilde hazırlanmak için spekülatif mantık eklemek , geleceğin beklediğinizden farklı olduğu ortaya çıktığında sizi kodunuzu yeniden düzenlemenize gerek kalmaz . Gereksiz / koşullu mantıkla ilgili bakım, eksik işlevsellik eklemek için daha sonra yeniden düzenleme yapmaktan ziyade bir sürdürülebilirlik problemidir.

Bu nedenle, şimdilik tüm programınızın ihtiyaç duyduğu işlemin başarılı olup olmadığını bilmek olduğundan, önerilen çözüm B (tek bir boolean döndürün) doğru yaklaşımdır. Gereksinim değişirse daha sonra istediğiniz zaman yeniden düzenleyebilirsiniz. Bu çözüm en basit ve en düşük karmaşıklığa sahip (KISS) ve sadece ihtiyacınız olanı ve daha fazlasını yapmıyor (YAGNI).

Satırların tamamı veya hata durumu

En azından çalışma zamanı seçeneği olarak tüm satırları döndürmeyi düşünün. DB eklerinde, eklenen verileri incelemeniz gerekebilir - çünkü genellikle DB'ye gönderdiğinizden farklı olacaktır; sık karşılaşılan örnekler arasında otomatik olarak oluşturulmuş satır kimlikleri (uygulamanın hemen ihtiyaç duyacağı), DB tarafından belirlenen varsayılan değerler ve bunları kullanırsanız tetikleyicilerin sonuçları yer alır.

Döndürülen veri gerekmiyorsa hatalar varsa o 0'a sonucu için yararlı olmadığından Öte yandan, o zaman da o zaman dönmek gerekir, etkilenen satır sayısı gerekmez ne tür bir proje hata işleme ilkelerinizle (istisnalar, sayısal hata kodları, her ne olursa olsun) tutarlı bir şekilde hata oluştu; ancak 0 satırı doğru şekilde etkileyecek geçerli sorgular vardır (gerçekte yoksa "süresi dolmuş tüm siparişleri sil").