1

I'm working on a database application that manages industry-specific inputs and then runs that information through somewhat complicated calculations, lookups, etc. to return a series of other values and a go/no-go conclusion.

I've decided to use Entity Framework (code first for provider independence) and WPF (MVVM pattern). I'm using the POCO entities as my data model and the view model is handling the usuals like basic data / business rule validation.

It seems EF + WPF/MVVM are great at displaying and validating input and getting it into the database for querying for your typical business application like a products, customers, orders setup. But it's not at all clear where to plug in a "calculations layer". Between the view models and the data models (my POCOs), things are already feeling a bit bloated, and now I'm facing adding another layer very much like the other two.

Perhaps the best way to approach this is to make the calculations layer a sort of meta-view model and push as much of the validations, change notification, etc. into them and run with lighter actual view models.

Anyone run into a situation like this?

Edit

Turns out what I really needed was to thin the view models and beef up the entities. So I lightened the view models, moved property change notification and basic validation to entities to allow for direct binding, and made calculation classes directly consume entities as well as adding some basic routines to entities. Thanks for the links on thought ADM articles @Peter Porfy.

For moving validation closer to entities, used Fluent Validation (excellent suggestion @Gloopy!). To make it easier to implement property changed notification on entities, adapted this technique. And to avoid having to create endless property wrappers in view model (to set HasChanges property) I used Josh Smith's PropertyObserver.

Community
  • 1
  • 1
N Jones
  • 1,004
  • 11
  • 18

2 Answers2

1

MVVM stands for Model-View-ViewModel, where the Model layer contains everything what models your actual domain problem.

So it depends on what you mean 'calculation layer'.

Put it where it belongs.

If the actual operation belongs to a domain entity, then you should put that logic into the entity. Don't make anemic domain models:

Article from Martin Fowler about ADM.

DDD works perfectly with EF code-first.

If something doesn't belong to any entity then probably you should expose that as a service. Then use that from your viewmodels through an interface.

A dependency injection container could make your life easier here, but you can live without it.

You aren't plugging another layer because it's the model layer. Your viewmodels should stay as thin as possible, just modelling your view's state and forwarding actual business operations to the entity/service classes.

Peter Porfy
  • 8,921
  • 3
  • 31
  • 41
  • After reading the ADM and DDD articles (and googling), it seems like a mix of extending my entities and creating a service class is the way to go. My hesitation with extending the entities has been that everyone eschews it, but also that it makes them more difficult to read/use. It becomes less clear what's a property in the data store and what's a computed property, there are lots of extra tags indicating what EF should ignore, etc. Am I overcomplicating it or is there a "safe" way to approach extending entities? – N Jones Jul 07 '12 at 16:18
  • I don't think that 'everyone eschews it', but you are right, more people going with ADM. That way you benefit from a clear procedural(!) style of doman layer but lose the benefits of OOP. It's up to everyone to choose and I believe both has it's place. With proper SOLID design (ggl it) it won't be less clear but more readable and followable. – Peter Porfy Jul 07 '12 at 18:21
  • All in all EF and other ORMs are to hide the fact that some pieces of your application's state are stored in the database so you can stay in OOP style coding. You shouldn't drop that benefit from your domain model. You can specify what to ignore in the datacontext configuration too if you don't want to mess your entities with attributes. – Peter Porfy Jul 07 '12 at 18:28
  • Don't think of it like 'extending the entities' because it's not extension but making real OOP classes with behavior. With SRP in mind of course. But you can go with ADM too, I see the benefits of it, it's just unnatural in OOP to pass around value objects everywhere. – Peter Porfy Jul 07 '12 at 18:34
0

I'd probably create an interface/object to handle calculations (or several if they can be split up logically) and pass that object in wherever you would want to use it. You might benefit from using a dependency injection framework maybe this post can help with that so you wouldn't have to explicitly instantiate your objects where you need them.

Also this post mentions FluentValidation.NET which may not apply completely but there are likely some good patterns to learn from/use there as well.

Community
  • 1
  • 1
Gloopy
  • 37,767
  • 15
  • 103
  • 71