dotNETportal.cz

Zdravím...

Při programování wpf aplikace jsem narazil na problém...Zjednoduším ho...

Chtěl bych takovouto strukturu databáze:

Mám nějakou krabici, ve které jsou různé tvary (krychle, koule, kužel, trajhran...)

Každý tvar dědí z rozhraní....

public interface ITvar
    {
        double PocitejObvod();

    }

    public class Krychle : ITvar
    {
        public double PocitejObvod()
        {
            //výpočet obovodu u krychle
        }
    }

    public class Koule : ITvar
    {
        public double PocitejObvod()
        {
            //výpočet obovodu u koule
        }
    }

    public class Krabice
    {
        public List<ITvar> Tvary { get; set; }
        public double ObjemKrabice { get; set; }
    }

Jak řeknu té v databázi té krabici, že může být koulí, či krychlí (ale vlastně čímkoliv jiným)???

Napadá mě přes nějakou mezitabulku... Nebo to nějak vymršit a pak si udělat pěkný ViewModel s rozhraníma a tak??

Ale jak tohle udělat dobře, tak aby se s tím EF popasoval?

Děkuji za pomoc

Pro EF se v databázi dědičnost nejčastěji řeší tak, že pro váš případ budete mít tyto tabulky:

Krabice - bude mít identity PK například IDKrabice a dále pole ObjemKrabice

Tvar - bude mít identity PK například IDTvaru a FK IDKrabice NULL na tabulku Krabice určující v jaké krabici se tvar aktuálně nachází (vazba 1:N - tvar může být aktuálně pouze v jedné z krabic, NULL pokud tvar v žádné krabici není)

Krychle - bude mít identity PK IDKrychle a FK IDTvaru k tabulce Tvar a U na IDTvaru (aby byla vazba 1:1)

Koule - bude mít identity PK IDKoule a FK IDTvaru k tabulce Tvar a U na IDTvaru (aby byla vazba 1:1)

V EF tomu budou odpovídat jednotlivé třídy pro entity tj. Tvar bude base třida, ze které budou třídy Krychle a Koule dědit. Pokud pak navíc budete chtít mít i interface ITvar tak se to nevylučuje tj. zavedení navíc tohoto interface EF vadit nebude (ale také mu jinak nepomůže).

Případně by šlo nechat v tabulkách Krychle a Koule IDTvaru jako PK, pokud se nikde nepotřebujete odkazovat pouze na krychli nebo kouli (přes IDKrychle a IDKoule).

Díky, díky..

Ono - koukám že viewModel se bude od toho mého databázového modelu značně lišit...

To ale nevadí ne? Od toho je ten viewModel..

Ještě mám jednu takovou doplňující otázku..

Jaká je rozdíl mezi mvvm a mvc - co jsem tak pochytil mělo by to být v tom, že ve mvvm komunikuje view s viewmodelem (oboustranně)?

Ano, ViewModel se od databázového modelu resp. modelu obecně liší hodně.

U MVVM (např. ve WPF/Silverlight/Knockuout JS) ViewModel drží a reprezentuje kompletní stavový obraz View. View a ViewModel spolu úzce spolupracují tj. View reaguje na změny stavu VM, mění ho (obousměrný binding) nebo volá definované commandy.

U MVC (např. v ASP.NET MVC) Controller rozhoduje jak se bude požadavek zpracovat, načítá nebo mění model, vybírá View. Když ale vybere view, jen mu předá model a nechá ho vyrenderovat. Přitom View model čte podobně jako čte ViewModel u MVVM. Dá se tedy říct, že v MVC do jisté míry odpovídá Model ViewModelu u MVVM. U MVC není sice obracená komunikace View => Model (jako View => VM u MVVM), ale to je spíše dáno charakterem toho, že se jedná o zpracování HTTP požadavku.