asp.net mvc - EF4 code-first vs model-first with regards to model validation -


i'm working on one-man asp.net mvc 3 project (i have complete control on database schema , code), , i'm trying decide between going database-first , poco w/ ef4 models, or if should go w/ code-first.

the main thing i'm trying achieve decorating models dataannotation attributes can enforce schema validation prior doing persistence. looking @ scott guthrie's article model validation w/ mvc 2, talks article doing code-first (step 2), , doing model-first (or database-first) using "buddy classes" (step 5).

i historically have done database design using sql server designer gui (and scripts), i'm more productive that, strictly when comes database design. however, unless ditch idea of decorating models w/ dataannotation attributes validation, violating dry not having model properties in 2 classes, having to, in essence, build schema in 2 places.

i'm looking that's had experience both methods (or 1 method), , can offer feedback on way went, why decided that, , how found work. i'd know if might better off going different, using tools fluent validation, or maybe abandoning domain model-level validation altogether, , keeping validation in services , view models.

firstly code first in ctp , therefore doesn't have go-live licence. if project delivered in next couple of months decision model first.

having said that, code first classes using dataannotations cleaner model first poco buddy classes important thing in experience explicit intent. long design clear , importantly consistent either approach suitable.

for small project (i.e 1 man you've stated) i'd you're more productive model first , designing through edmx. feel more comfortable coming schema first background. there number of hoops you'll need jump through poco classes working nicely such installing poco t4 template modifying t4 template created in project pull poco's separate assembly. don't want them in dal assembly start off. you're left decision of how comfortable partial classes implementing dataannotations; reasons don't agree many people see these poor design.

in mvc project you'll hit ubiquitous dry problem using dataannotations either approach when decide use viewmodels. @ point you'll realise extensive annotation of model validation useful if happy sending these classes directly view. if decide keep views lightweight , use viewmodels have repeat dataannotations on viewmodel otherwise you're left validation errors @ model level no way of getting modelstate other manually adding. neither code first or model first solve problem yet need design accordingly. went mix , accepted level of breaking dry.


Comments

Popular posts from this blog

c# - How to set Z index when using WPF DrawingContext? -

razor - Is this a bug in WebMatrix PageData? -

visual c++ - Using relative values in array sorting ( asm ) -