Diyelim ki bir çeşit veritabanında var olan bir çeşit veri yapınız var. Basit olması için, bu veri yapısı diyelim Person
. Artık diğer uygulamaların oluşturmasına, okumasına, güncellemesine ve silmesine izin veren bir CRUD API'si tasarlamakla görevlisiniz Person
. Basit olması için, bu API'ya bir tür web hizmeti üzerinden erişildiğini varsayalım.
CRUD'nin C, R ve D parçaları için tasarım basittir. C # benzeri fonksiyonel gösterim kullanacağım - uygulama SOAP, REST / JSON veya başka bir şey olabilir:
class Person {
string Name;
DateTime? DateOfBirth;
...
}
Identifier CreatePerson(Person);
Person GetPerson(Identifier);
void DeletePerson(Identifier);
Güncelleme ne olacak? Yapılacak doğal şey,
void UpdatePerson(Identifier, Person);
ancak hangi alanların Person
güncelleneceğini nasıl belirlersiniz ?
Gelebileceğim çözümler:
Her zaman tam bir Kişinin geçmesini isteyebilirsiniz , yani müşteri doğum tarihini güncellemek için böyle bir şey yapar:
p = GetPerson(id); p.DateOfBirth = ...; UpdatePerson(id, p);
Bununla birlikte, Get ve Güncelleme arasında bir tür işlem tutarlılığı veya kilitlenmesi gerekir; aksi takdirde, başka bir müşteri tarafından paralel olarak yapılan diğer değişikliklerin üzerine yazabilirsiniz. Bu, API'yi çok daha karmaşık hale getirecektir. Buna ek olarak, aşağıdaki sahte koddan (JSON desteğiyle bir istemci dili varsayarak) hata eğilimli
UpdatePerson(id, { "DateOfBirth": "2015-01-01" });
- doğru görünen - yalnızca DateOfBirth değerini değiştirmekle kalmaz, diğer tüm alanları da null değerine sıfırlar.
Tüm alanları yoksayabilirsiniz
null
. Ancak, bunu değiştirmemekDateOfBirth
ve kasıtlı olarak null değerine değiştirmek arasında nasıl bir fark yaratırsınız ?İmzayı olarak değiştirin
void UpdatePerson(Identifier, Person, ListOfFieldNamesToUpdate)
.İmzayı olarak değiştirin
void UpdatePerson(Identifier, ListOfFieldValuePairs)
.İletim protokolünün bazı özelliklerini kullanın: Örneğin, Kişinin JSON temsilinde bulunmayan tüm alanları yoksayabilirsiniz. Ancak, bu genellikle JSON'u kendiniz ayrıştırmanızı ve kitaplığınızın yerleşik özelliklerini (örneğin WCF) kullanamamanızı gerektirir.
Hiçbir çözüm benim için gerçekten zarif görünmüyor. Elbette, bu yaygın bir sorundur, peki herkes tarafından kullanılan en iyi uygulama çözümü nedir?
Person
Hala devam etmeyen yeni oluşturulan örnekler için ve tanımlayıcı, kalıcılık mekanizmasının bir parçası olarak kararlaştırıldığında, bunu null değerine bırakın. Cevaba gelince, JPA bir sürüm numarası kullanıyor; sürüm 23'ü okursanız, DB'deki sürüm 24 ise öğeyi güncellediğinizde yazma işlemi başarısız olur.