İş mantığında veritabanı değerlerine referans verme

Sanırım bu zor kodlama ve en iyi uygulamalar hakkında başka bir soru. Diyelim ki bir değerler listesine sahibim, veritabanında depolanan meyve diyelim (tablonun SSRS raporları gibi diğer amaçlar için kullanıldığı veritabanında olması gerekir), bir ID ile:

1 Apple 
2 Banana 
3 Grapes

Onları kullanıcıya sunabilirim, bir tanesini seçer, FavouriteFruit olarak profilinde saklanır ve veritabanındaki kaydında bulunan ID.

İş kuralları / etki alanı mantığı söz konusu olduğunda, mantığı belirli değerlere atamak için öneriler nelerdir? Kullanıcı Üzümleri seçtiyse, fazladan bir görev yapmak istiyorum, Üzüm değerine başvurmanın en iyi yolu nedir:

// Hard coded name
if (user.FavouriteFruit.Name == "Grapes")

// Hard coded ID
if (user.FavoriteFruit.ID == 3) // Grapes

// Duplicate the list of fruits in an enum
if (user.FavouriteFruit.ID == (int)Fruits.Grapes)

veya başka bir şey?

Elbette FavouriteFruit, başvuru boyunca kullanılacağından, liste eklenebilir veya düzenlenebilir.

Birileri 'Grape'nin' Grape 'olarak yeniden adlandırılmasını isteyip istemediğine karar verebilir ve bu elbette kodlanmış dize seçeneğini bozacaktır.

Sabit kod kimliği tamamen net değildir, ancak gösterildiği gibi, hangi öğenin hızlı bir şekilde olduğunu belirlemek için bir yorum ekleyebilirsin.

Enum seçeneği, senkronizasyondan çıkabileceği için yanlış görünen veritabanından veri kopyalamayı içerir.

Neyse, yorum veya önerileriniz için şimdiden teşekkür ederiz.

Her ne pahasına olursa olsun, dizeleri ve sihirli sabitleri kaçının. Tamamen söz konusu değiller, seçenek olarak bile düşünülmemeliler. Bu, sizi yalnızca tek bir uygulanabilir seçenek olarak bırakıyor gibi görünüyor: tanımlayıcılar, yani enums. Ancak bence en iyisi olan bir seçenek daha var. Bu seçeneğe "Önceden Yüklenmiş Nesneler" diyelim. Önceden Yüklenmiş Nesnelerle, aşağıdakileri yapabilirsiniz:

if( user.FavouriteFruit.ID == MyApplication.Grape.ID )

Burada olan şey, açık bir şekilde tüm satırı Grapebelleğe yükledim, bu yüzden kimliğini karşılaştırmalarda kullanmaya hazırım. Nesne İlişkisel Eşleme (ORM) kullanıyorsanız, daha da iyi görünür:

if( user.FavouriteFruit == MyApplication.Grape )

(Bu yüzden "Önceden Yüklenmiş Nesneler" olarak adlandırıyorum.)

Bu nedenle, başlangıç ​​sırasında tüm "numaralandırma" tablolarımı (haftanın günleri, yılın ayları, cinsiyetler vb. Küçük tablolar) ana uygulama alanı sınıfına yüklüyorum. Onları isimle yüklüyorum, çünkü açıkça MyApplication.Grape"Üzüm" adlı satırı almalı ve her birinin bulunduğunu iddia ediyorum. Aksi halde, başlatma sırasında, tüm çalışma zamanı hatalarının en az zararı olan garantili bir çalışma zamanı hatamız vardır.

Dizeye karşı kontrol etmek en okunaklı olanıdır, ancak iki görevi vardır: hem tanımlayıcı hem de açıklama olarak kullanılır (alakasız nedenlerle değişebilir).

Genelde her iki görevi de ayrı alanlara bölerim:

id  code    description
 1  grape   Grapes
 2  apple   Apple

Tanımın değişebileceği yerlerde ("Üzümler" yerine "Muz" değil), ancak kodun hiçbir zaman değişmesine izin verilmez.

Bu çoğunlukla, çünkü kimliklerimiz neredeyse her zaman otomatik olarak üretiliyor ve bu nedenle uygun değil. Kimlikleri özgürce seçebiliyorsanız, her zaman doğru olduklarını garanti edebilir ve bunları kullanabilirsiniz.

Ayrıca, birileri gerçekten "Üzümleri" "Üzümler" olarak ne sıklıkta düzenler? Belki bunların hiçbiri gerekli değildir.

Burada beklediğiniz şey, değişen verilere otomatik olarak uyarlanabilen programlama mantığıdır. Enum gibi basit statik seçenekler burada çalışmaz, çünkü çalışma zamanına ek olarak sayılar ekleyemezsiniz.

Gördüğüm birkaç desen:

• Programınızın gününü mahvedecek yepyeni bir veritabanı girişine karşı koruma sağlamak için Enums + default.
• Veritabanında yapılacak işlemlerin kodlanması (biz mantık). Birçok durumda bu çok olasıdır çünkü birçok mantık yeniden kullanılır. Mantığın uygulanması programda olmalıdır.
• Programın doğru konuşlanana kadar yepyeni değerini programda "yoksayılacak" olarak işaretlemek için veritabanındaki ekstra özellikler / sütunlar.
• Veritabanından değerleri yükleyen / yeniden yükleyen kod yolunun çevresindeki hızlı mekanizmalar. (İlgili eylem programda değilse VE ihmal edilmek üzere işaretlenmediyse, yenilemeyi yapmayın).

Genel olarak, verinin, eylemlerin kendileri başka bir yerde de uygulanabilse bile, ima ettiği eylemlere gönderme anlamında eksiksiz olmasını seviyorum. Verilerden bağımsız eylemleri belirleyen herhangi bir kod, muhtemelen muhtemelen birbirinden ayrılacak ve hatalara yol açacak olan veri gösterimini paylaştı.

Bunları her iki yerde (bir tabloda ve bir ENUM'de) saklamak o kadar da kötü değil. Sebep şu:

Bunları bir veritabanı tablosuna kaydederek, veritabanındaki referans bütünlüğünü yabancı anahtarlar aracılığıyla zorlayabiliriz. Yani bir kişiyi veya meyveyi ne tür bir varlık ile ilişkilendirirseniz, bu sadece veritabanı tablosunda bulunan bir meyvedir.

Bunları bir ENUM olarak saklamak da anlamlıdır çünkü sihirli dizeler olmadan kod yazabiliriz ve bu kodu daha okunaklı hale getirir. Evet, senkronize olmaları gerekir, ancak ENUM'a bir satır ve veritabanına yeni bir insert ifadesi eklemek ne kadar zor olurdu.

Bir ENUM tanımlandıktan sonra değeri değiştirmez. Örneğin, eğer olsaydı:

• elma
• Üzüm

Grape'yi Grapes olarak değiştirmeyin. Basitçe yeni bir ENUM ekleyin.

• elma
• Üzüm
• üzüm

Verileri taşımanız gerekirse, tüm Üzümleri Üzümlere taşımak için bir güncelleme uygulayın.

Bu soruyu sormakta haklısın, yanlış koşulların değerlendirilmesine karşı savunma yapmaya çalışırken aslında güzel bir soru.

Bununla birlikte, değerlendirmenin ( ifşartlarınız) mutlaka etrafından nasıl geçeceğinizin odağı olması gerekmez. Bunun yerine, 'senkronizasyon dışı' sorununa neden olacak değişiklikleri yayma biçiminize dikkat edin.

Dize Yaklaşımı

Dizeleri kullanmanız gerekiyorsa, listeyi UI aracılığıyla değiştirme işlevini neden göstermiyorsunuz? Sistemi , örneğin, şu anda başvuruda bulunan tüm kayıtları güncelledikten sonra değiştirecek Grapeşekilde tasarlayın .GrapesGrape

Kimlik Yaklaşımı

Bazı okunabilirliklerin uzlaşmasına rağmen her zaman bir kimliğe başvurmayı tercih ederim. The list may be added toBöyle bir UI özelliğini ortaya çıkarırsanız, size bildirilecek bir şey olabilir. Kimliği değiştiren öğelerin yeniden sıralanması ile ilgileniyorsanız, böyle bir değişikliği tekrar tüm bağımlı kayıtlara yayın. Yukarıdakilere benzer şekilde. Başka bir seçenek (uygun normalizasyon kurallarını takip ederek, bir enum / id sütununa sahip olmak ve - FruitDetailarayabileceğiniz bir "Sipariş" sütununa sahip daha ayrıntılı bir tabloya başvurmak olacaktır ).

Her iki durumda da, listenizdeki değişikliği veya güncellemeyi kontrol etmeyi önerdiğimi görebilirsiniz. Bunu bir ORM veya başka bir veri erişimi kullanarak yapıp yapmadığınız, teknolojinizin özelliklerine göre belirlenir. Esasen yaptığınız şey, bu tür değişiklikler için DB'den uzak olan insanlara - ki bence sorun değil. Çoğu ana CRM aynı şartı sağlayacaktır.

Çok yaygın bir problem. Veri müşteri tarafını çoğaltmak DRY ilkelerini ihlal ediyor gibi görünse de , bu gerçekten katmanlar arasındaki paradigma farkından kaynaklanmaktadır.

Enum (ya da her neyse) veritabanı ile adım dışında olması da bu kadar nadir değildir. Henüz istemci tarafı kodunda kullanılmayan yeni bir raporlama özelliğini desteklemek için bir meta veri tablosuna başka bir değer vermiş olabilirsiniz.

Bazen başka türlü de olur. İstemci tarafına yeni bir enum değeri eklenir, ancak DB güncelleştirmesi, DBA'nın değişiklikleri uygulayabileceği süreye kadar gerçekleşemez.

Temelde statik bir arama olan şeyden bahsettiğimizi varsayarsak, üçüncü seçenek olan - enum - temelde tek aklı başında seçimdir. Eğer veritabanı dahil olmasaydı ne yapardın, mantıklı geliyordu.

Daha sonra soru, veritabanında numaralandırmaların ve statik / arama tablolarının nasıl senkronize edileceği ile ilgili bir soru haline gelir ve ne yazık ki bu henüz tam bir cevabım yok.

Seçim yaparak tüm şema bakımlarımı kod olarak yapıyorum ve bu nedenle uygulamanın bir yapısı ile beklenen bir şema sürümü arasındaki ilişkiyi koruyabilirim; yap. Daha otomatik olsaydı daha iyi olurdu (ve aynı zamanda enums'lerin ve aramaların eşleşmesinin de yardımcı olmasını sağlamak için otomatik bir entegrasyon testi) ama bu daha önce uyguladığım bir şey değil.