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:

article martin fowler adm.

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

Popular posts from this blog

javascript - backbone.js Collection.add() doesn't `construct` (`initialize`) an object -

php - Get uncommon values from two or more arrays -

Adding duplicate array rows in Php -