Program do faktur - jak zaprojektować

Chciałbym sobie napisać mały prosty programik do wystawiania faktur ale ugrzązłem na etapie projektowania.

Na razie zrobiłem sobie bazę danych, w której mam tabele:

Towary
Klienci
Faktura_Naglowek
PozycjeFaktury

Jakie klasy powinien zawierać taki projekt. Domyślam się, że potrzebuję klas:

Towar
Klient
Faktura

Myślałem jeszcze żeby dodać klasę PozycjaFaktury, która reprezentowała by towar dodany na fakturę wraz z jego ilościami i innymi informacjami o nim, tylko się zastanawiam czy taka klasa PozycjaFaktury powinna dziedziczyć po klasie Towar, czy zawierać klase Towar.

Może ktoś ma doświadczenie z takimi aplikacjami, więc bardzo proszę o radę jak to wszystko zaprojektować żeby miało ręce i nogi(nie chcę również używać w tym projekcie EntityFramework'a ani innych podobnych, chciałbym wszystko ręcznie zrobić).

może pokaż cały schemat bazy żeby można się było wypowiedzieć

Na razie schemat bazy wygląda tak. Chcę zidentyfikować potrzebne w programie klasy i powiązania między nimi. Oczywiście baza będzie się jeszcze zmieniać.

A tak z ciekawości, w czym narysowałeś schemat bazy danych?

goodfather napisał(a):

Oczywiście baza będzie się jeszcze zmieniać.
a wraz z każdą zmianą będziesz zmieniał połowę programu... Jeśli robisz to na poważnie to najpierw skup się na zaprojektowaniu porządnie bazy.

1. NIP nie jest dobry jako klucz główny - nie każdy go musi mieć (chyba, że zakładasz, że tylko z nipem będziesz handlował) i nie do końca jest unikalny. A co z kontrahentami, którzy mają kilka adresów i na każdym ten sam nip?
2. dla wszystkich kontrahentów masz tą samą cenę? Bez upustów, rabatów itp? Dla różnych cen zakupu masz zawsze tą samą cenę sprzedaży? Wszystkie towary są z taką samą stawką VAT?
3. dany towar ZAWSZE dostarcza Ci ten sam dostawca? Nie chcesz pamiętać ceny zakupu?
4. nie będziesz ewidencjonował ceny zakupu?
5. nie chcesz znać stanu towaru na magazynie?
6. niebezpieczne jest trzymanie w nagłówku faktury tylko ID kontrahenta a w pozycjach tylko ID towaru. Nie masz historii zmiany rekordów. Ktoś Ci zmieni nazwę kontrahenta i we wszystkich "starych" fakturach też się to zmieni i jak Ci przyjdzie wydrukować kopię to leżysz.

1. Będą tylko klienci z NIPem
2. Na razie tego nie chcę rozróżniać
3. Na razie nie
4. nie
5. nie

To ma być na razie dla mnie "wprawka" do większego projektu, więc chciałem się tylko dowiedzieć czegoś od strony kodowania w C# bo od strony bazy to wiem że to co mam jest strasznie niekompletne. Głównie chodzi mi o zarys klas jakie były by przydatne i powiązania między nimi.

Na obrazach google znalazłem coś takiego, nie wiem na ile to poprawne i czy w ogóle Ci pomoże, ale zawsze coś ;) - http://info.wsisiz.edu.pl/~cholajda/relacje_2000.gif

No dobra, a już pomijając kwestie bazy, to czy klasa PozycjaFaktury, która reprezentuje towar, jego ilosc i inne parametry na fakturze powinna dziedziczyć po klasie Towar?

goodfather napisał(a):

No dobra, a już pomijając kwestie bazy, to czy klasa PozycjaFaktury, która reprezentuje towar, jego ilosc i inne parametry na fakturze powinna dziedziczyć po klasie Towar?

A w jakim celu miałaby dziedziczyć?

somekind napisał(a):

goodfather napisał(a):

No dobra, a już pomijając kwestie bazy, to czy klasa PozycjaFaktury, która reprezentuje towar, jego ilosc i inne parametry na fakturze powinna dziedziczyć po klasie Towar?

A w jakim celu miałaby dziedziczyć?

Nie wiem, właśnie chcę to ustalić :)
Czyli np klasa PozycjaFaktury powinna wygladać mniej więcej tak:

 
class PozycjaFaktury
{
  Towar towar;
  decimal ilosc;
  int rabat;

 //itd

}

Tak to wypadało by zrobić?

To jeszcze jedno pytanie. Chciałbym, żeby pewne wartości obliczały się automatycznie po zmianie innych wartości np wartość i cena powinny się zmieniać jeśli zmienia się np rabat
Czy w takim razie powinienem we właściwości Rabat wykonywać te obliczenia? np:

Rabat
{
 get{return rabat;}
 set{ 
     rabat = value;
     cena = towar.cena-towar.cena*rabat;
     wartosc = ilosc * cena;
     }

}

Tak by to należało zrobić? Bo mi się tu trochę wątpliwości nasuwają, bo niektóre właściwości powinny zależeć od kilku innych właściwości co spowoduje że sekcja set zrobi się strasznie rozbudowana w wielu właściwościach. Np.

• rabat wpływa na cene i wartość
• ilosc wpływa na cene i wartosc
• cena wpływa na wartość
  itp , tych zależności może być bardzo dużo. Jak to ładnie zrobić?

ja jestem zdania, że jeśli program ma operować takim pojęciem jak rabat to ceny muszą być co najmniej dwie - cena podstawowa i cena z upustem (cena po rabacie) i obie finalnie powinny się znaleźć w bazie razem z innymi danymi. Dlatego też wg mnie poprawniej jest coś w ten deseń

• cena (po zmianie aktualizacja ceny z rabatem)
• cena z rabatem (po zmianie aktualizacja wartości)
• rabat (po zmianie aktualizacja ceny z rabatem)
• ilość (po zmianie aktualizacja wartości)

i teraz np. zmiana ceny pociąga za sobą zmianę ceny z rabatem a ta zmianę wartości

abrakadaber napisał(a):

...

No tak też jest, tylko jak to sprytnie zrobić? Czy wszystko przeliczać we właściwościach i wywoływać jakieś zdarzenie po zmianach, czy zrobić to jakoś całkiem innaczej.

no przecież jeśli masz właściwość cena, która w setcie zmienia właściwość (a nie zmienną!) cena_z_upustem, która zmienia w setcie właściwość wartość to jak zmienisz na początku łańcuszka to potem się potoczy samo. Dodatkowo jeśli będziesz miał jakieś sprawdzenia, że np. wartość po rabacie nie może być mniejsza niż 100zł (bo np. rabat dopiero od 100zł) to jak zmienisz sam rabat to Ci się wykrzaczy na setcie wartość i w efekcie nie pozwoli przypisać rabatu