DDD principlers a ASP.NET MVC projektování

hlasů
5

Dvě otázky část

Mám agregát produkt, který;

Ceny PackagingOptions ProductDescriptions ProductImages etc

Jsem modelován jeden produkt úložiště a netvořila individuální úložišť pro některou z dětských tříd. Všechny operace db jsou řešeny přes archivu produktu.

Mám pochopení konceptu DDD správně tak daleko? Někdy otázka přijde na mysl, že má úložiště pro řekněme možnosti balení by mohl můj život jednodušší přímo načítání možnost obalový z DB pomocí jeho ID namísto požadavku na úložiště produktu ho najít v jeho sbírce PackagingOptions a dát to pro mě ..

Druhá část je řízení edit vytvořit operací pomocí ASP.MVC rám práce

V současné době jsem se snaží řídit všechny add editovat odstranit z těchto dětských sbírek produktu prostřednictvím regulátoru produktu (zvuk v pořádku?).

Jedním z problémů jsem nyní čelí, je;

Mám-li upravit konkrétní možnost obalového výrobku prostřednictvím

mydomain / produktu / editpackagingoption / 10

Mám přístup k id volby obalového

Ale nemám ID produktu za samozřejmé, a to nutí mě k napsání dotazu nejprve najít produkt, který má k tomuto konkrétnímu Možnosti balení pak upravit, aby výrobek a revelant možnost balení. Dokážu to jako všechny varianty obalového mají své unikátní identifikační číslo, ale to by selhat, pokud mám kolekcí, které nemají jedinečný identifikátor.

Že se cítí velmi špatně ..

Další možností jsem si myslel vysílá oba ID volitelných produktů a balení na adresu URL, jako je;

mydomain / produktu / editpackagingoption / 3/10

Ale nejsem si jistý, jestli to je dobrý design jeden.

Takže jsem v bodě, který jsem trochu zmatený. Možná bude mít zásadní nedorozumění kolem všechno ...

Ocenil bych, pokud si nesou s dlouhou otázku a pomoz mi dát to dohromady. dík!

Položena 27/08/2009 v 00:32
zdroj uživatelem
V jiných jazycích...                            


2 odpovědí

hlasů
3

V mé mysli, je to jeden z těch blátivých věcí, které se objeví v DDD.

V kódu, chovám agregační kořen jako kontejner pro všechny „vztahy“ Má to i jakýchkoli objektů subjekt, který nemůže existovat bez Aggregate kořene.

Například, pojďme se podle přání zákazníka> Order-> LineItem-> ukázkový produkt, který byl utlučen k smrti teď. Souhrnný kořen, jak jsem ji zobrazit, je zákazník v tomto scénáři. Že bylo řečeno, ne vždy se chtějí dostat do objednávky prostřednictvím zákazníka. Možná budete chtít najít příkazy k určitému datu.

Zapnutí je to strana, také nebude mít zákazník, který nemá objednávku. Oba jsou v poněkud symbióze tak jeden není agregát kořen druhé.

Jde o to, že si nepřejete, aby nahrát zákazníka přes objednávky, ale nemusí nutně chtít nahrát objednávky prostřednictvím zákazníka buď.

Od řádu, nicméně, to je nepravděpodobné, že byste chtěli, aby jen načíst LineItem a vy jistě nebude jejich vytvoření w / o objednávce. Za tímto účelem se řád slouží jako brána do LineItems. LineItems nebude potřebovat svůj vlastní ovladač, nebo úložiště. Existují pouze v samotném řádu a jako takové jsou součástí řádu (v tomto případě, objednávka se stává souhrnný kořen) a jsou řízeny objednávky osobou.

Ovšem i řádkové položky bude pravděpodobně mít vztah k výrobku v rámci systému. Produkty by měly své vlastní ovladače, úložišť apod protože mohou existovat mimo agregátu kořene.

V souhrnu mého nesourodý, mám tendenci dívat se na to takhle: pokud subjekt může existovat sama o sobě, měl by mít správce. Subjekty, které nemohou existovat samy o sobě (LineItems v tomto případě), by měla být řízena pouze pouze na základě kontejneru (agregát kořenové).

Budou některé DDD puristický prosím opravte mě, jestli / kde se pletu?

Co se týče druhé části vaší otázky, já bych potřebovat nějaké další podrobnosti o tom, jak si představujete těchto jiných subjektů pracujících. S tím, co jste tady řečeno, já bych si představit, že PackagingOptions souvisejí s produktem a bude součástí kořen kameniva zboží. Nyní, což znamená, že jste úpravách jim vyvolává otázku, je to vyhledávací tabulky v systému nebo jsou jednorázové hodnoty a jako takové by měly být považovány za hodnotové objekty?

Odpovězeno 27/08/2009 v 01:33
zdroj uživatelem

hlasů
1

kaivalya,

Pokud jde o vaši poslední poznámku (http bez státní příslušnosti):

Záleží na kontextu. Než se dostane do detailů, měl bych vám říci jednu ze základních zásad o agregátů:

Agregáty definovat skupinu souvisejících objektů, které by měly být považovány za jednu jednotku za účelem změny dat.

To je nesmírně důležité. Účelem s agregáty prosadit invarianty. Například může mít politiku jako „Příkaz nemůže přesáhnout $ 500“. Pak se prosadit tuto politiku, dáte pořádek a OrderItem společně v objednávkovém Aggregate. Tímto způsobem, kdykoli přidat novou OrderItem, je třeba dodat přes Order objektu. Zde můžete zkontrolovat celkovou cenu a ujistěte se, že nepřesáhne $ 500 mm. Pokud nechcete mít takové neproměnné v doméně, pak není důvod nahrává všechny tyto objekty dohromady.

Nyní, dostat zpět na váš komentář:

Pokud máte invarianty, které by měly být prosazovány, pak je to v pořádku načíst celý agregát, i když to může mít nějakou režii. Ano, HTTP je bez státní příslušnosti a načíst celý agregát jen pro úpravu jednoho ze svých podřízených objektů a pak vyhodit. To je v pořádku. Co je důležité, nejvíce je, že jste prosazování své neproměnné. To je to, co je pro DDD.

Účelem DDD je zachytit všechny obchodní logiky ve vaší doméně. Dalo by se určitě dosáhnout lepší výkon, pokud jste neměli načíst celý agregát, ale jak byste prosazovat svá invariants? Byste s největší pravděpodobností muset udělat ve své uložené procedury. Ano, to funguje, a to je velmi jednoduché, ale jednání s obchodními logiky v uložených procedur při údržbě je noční můra. To je důvod, proč se DDD vyvinula. Takže si můžete modelovat své obchodní požadavky za použití objektově orientované jazyky / tools, takže jsou snáze pochopitelný a upravit.

Jen pamatujte, že DDD je skvělý přístup, ale ne pro všechny typy projektů. Pokud máte co do činění s projektem, v němž existuje spousta obchodních logik a šance na jejich měnící se vzhledem k povaze podniku je vysoká, pak byste měli použít DDD. Nicméně, pokud váš projekt je více „něco přečíst / psát něco“ bez větších obchodní logiky zapojené pomocí DDD je bolest hlavy. Dalo by se jednoduše použít LINQ to SQL (nebo SqlDataAdapters) a odeslat předměty na vaše názory. Vy ani nemusíte starat o hledání subjektů, z toho hodnota objekty, kameniva, úložištích, atd.

Snad to pomůže,

Mosh

Odpovězeno 06/04/2010 v 08:58
zdroj uživatelem

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more