Gayet temiz ve profesyonel gozukuyor, hem kodunuz hemde tasariminiz. Gerçek projelerin çoğu bukadar temiz olmuyor. Okul projesi sonuçta çokta şey etmemek lazım.
Gözüme takılan tek şey Revenues ve Expenses için ayrı tablo tutmanız. Bilanço filan çıkarılırken bu işinizi zorlaştırır diye düşünüyorum bunların benzer ortak özellikleri var. Mesela bir girdinin de çıktının da faturası olmak zorunda.
Ben olsam böyle yapardım
public enum TransactionType{
Expense,
Revenue
// tabi bu genisletilebilir
}
public enum InvoiceType {
Received,
Issued
}
// sonucta her enitityde nezaman yaratildi nezaman guncellendi, id gibi fieldlar var
public class BaseEntity {
[Key]
public Id int
public DateTime Created { get; set;}
public DateTime Updated { get; set; }
// eger soft delete yapılacaksa
public DateTime DeletedAt { get; set; }
public string Reason { get; set; }
}
Revenue ve expenses icin tek bir tablom olurdu, ikisi arasindaki farkı enum ile sağlardım
// kesilen alinan tum faturalari burda tutardim
public class Invoice : BaseEntity {
// Id, Created, Updated, Deleted fieldlari BaseEntity den geliyor zaten.
// Kesilen, Alinan faturalar ... Genisletilebilir
public InvoiceType InvoiceType { get; set; }
public DateTime PaymentDate { get; set; }
// Faturanin odeme zamanını tutuyorsun, o yuzden irsaliyeye
// kesilip kesilmediğini tutmak mantıklı olabilir.
public bool IsForwarding { get; set; }
// Her transactionın bir faturası var, her faturada bir transaction ile iliskili
// 1:1
public int TransactionId { get; set; }
public Transaction Transaction { get; set; }
// burasida gelistirilebilir, InvoiceItem diye baska bir entitin olur
// one:many relationship ile fatura ile iliskilendirirsin.
// Faturadaki her urun hizmet vs ayri ucret yazilabilir
public double Amount { get; set; }
}
public class Transactions: BaseEntity {
// Id vs fieldlar base entityden geliyor
// girdi cikti, abonelerden alinan girdi vs
public TransactionType TransactionType { get; set; }
// her transactionin bir faturasi yada ibrazi olmak zorunda
public int InvoiceId { get; set; }
public Transaction Transaction { get; set; }
// transaction eger bir uye ile iliskiliyse
// dikkat etmeniz gereken burdaki ilişki opsiyonel.
// ama bence bu olmaması gereken bir durum.
// mesela bir aidat gelecekse o aidat zaten fatura ile iliskili
// fatura da subscription ile iliskili, subscriptionda member ile iliskili
// gerekli ise member zaten dolayli yoldan ( invoice > subscription > Member) iliskili|
// burdaki Member referansi olmadanda ufak bir join islemi ile membera ulasabilirsiniz
// https://learn.microsoft.com/en-us/ef/core/querying/related-data/eager
public int? MemberId { get; set; }
public Member? Member { get; set; }
}
kafanizda kurdugunuz bussiness yapısını bilmedigimden buna cok yorum yapamıyorum. Ama subsriptıon classınızda bir fatura referansı eksik gibi geldi. Aidat icin zaten bir fatura olusturuyorsunuz. Fatura oluştururken zaten fatura ile birlikte Transaction da olusturacaksiniz. yani bu faturayi istediğiniz gibi bilançonuzda kullanabilirsiniz
public class Subscription: BaseEntity {
....
public int InvoiceId { get; set; }
public Invoice Invoice{ get; set; }
}
Şema ile daha anlaşılır olur sanırsam. Goruldugu dolaylıda olsa gibi hepsi bir biri ile ilişkili
https://dbdiagram.io/d/OkulProje-662ef3ba5b24a634d00512d6
Umarım yararlı olabilmişimdir, başarılar dilerim çok temiz bi proje yapmışsınız. Bunun en uç noktası Mvvm yada Mvu gibi patternlerin implemente edilmesi.
