DAL-> Design :: jednoduchý vs. optický model && vlastnosť vs metóda - oop, model, data-access-layer

Predpokladajme, že chcete implementovať Data Access Layer, ktorá sa postará o uloženie (java) objektu do úložiska údajov.

Model vo vašom obchode predstavuje entitu (tabuľka v sql), jednotka má členov, ktorí buď obsahujú informácie o samotnej entite, alebo o vzťahu k materskej entite (napr. ParentId).

Teraz sú tieto prípady:

1. model má členov s jednoduchými typmi údajov(int, char, String). Toto je najpoužívanejší prípad? Vaši členovia sú silne napísaní a bezpečne pristupovaní v celej aplikácii, ale pre každú entitu budete potrebovať ďalšie.

2. ako je uvedené vyššie, ale pre jednoduchosť arozšírenia, ste sa rozhodli implementovať svoj model ako mapu. Je to podobné ako v dátovom úložisku API AppEngine. Vaši členovia sú prístupní podľa mena vo vašej aplikácii, ale máte jeden všeobecný druh a všetky entity sa dajú ľahko rozšíriť.

3. model má iné modely ako členovia, nazývame tomodelu. tentoraz môžete vo svojom modeli získať všetky relačné entity. DAL je menej flexibilný a môžete zvýšiť alebo znížiť problémy s konzistenciou, ale teraz môžete používať OOP na úrovni modelu.

Dúfam, že som niečo vynechal. Na základe vašich skúseností, čo je podľa vás najlepšie prostredie pre najlepší prístup? myslím, že nie veľké podnikové aplikácie, ale skôr štandardný projekt.

Vďaka!

odpovede:

Odporúčam vám čítať agregáty vzor ako súčasť DDD (doménovo riadený dizajn). Základnou myšlienkou je rozdeliť váš model celej entity do logických skupín a potom poskytnúť úložisko pre každý súhrnný koreň (hlavná entitaskupiny), ktorá ušetrí všetky subjekty, ktoré tvoria súhrn. Tým sa plne využíva OOP, pričom sa neriešia otázky konzistentnosti. Vo všeobecnosti som zistil, že ide o najviac „organizovaný“ prístup.