design patterns - Entity Framework, MVVM, and Calculations Classes -
i'm working on database application manages industry-specific inputs , runs information through complicated calculations, lookups, etc. return series of other values , go/no-go conclusion.
i've decided use entity framework (code first provider independence) , wpf (mvvm pattern). i'm using poco entities data model , view model handling usuals basic data / business rule validation.
it seems ef + wpf/mvvm great @ displaying , validating input , getting database querying typical business application products, customers, orders setup. it's not @ clear plug in "calculations layer". between view models , data models (my pocos), things feeling bit bloated, , i'm facing adding layer other two.
perhaps best way approach make calculations layer sort of meta-view model , push of validations, change notification, etc. them , run lighter actual view models.
anyone run situation this?
edit
turns out needed thin view models , beef entities. lightened view models, moved property change notification , basic validation entities allow direct binding, , made calculation classes directly consume entities adding basic routines entities. links on thought adm articles @peter porfy.
for moving validation closer entities, used fluent validation (excellent suggestion @gloopy!). make easier implement property changed notification on entities, adapted this technique. , avoid having create endless property wrappers in view model (to set haschanges property) used josh smith's propertyobserver.
mvvm stands model-view-viewmodel
, model layer contains models actual domain problem.
so depends on mean 'calculation layer'.
put belongs.
if actual operation belongs domain entity, should put logic entity. don't make anemic domain models:
ddd works ef code-first.
if doesn't belong entity should expose service. use viewmodels through interface
.
a dependency injection container make life easier here, can live without it.
you aren't plugging layer because it's model layer. viewmodels should stay thin possible, modelling view's state , forwarding actual business operations entity/service classes.
Comments
Post a Comment