0

I will display a grid of a view model class M {string A, int B, float C, int D, .....}:

  1. Render the number in red if it's negative.
  2. Highlight the background of the cell if A is in 'xxx', 'zzz' and B = 0 or D > 200...
  3. Set the background of the row to grey if E > 100 and F < 0....

Are these considered business logic? Where to put these logic if they are? For (3), I guess a new read-only property can be created in in the view model? But it make the M not POJO/POCO any more? I read that the business logic should be in domain object. Is the domain object implemented using POJO/POCO?

Is there any code sample shows how the business logic is stored in domain objects?

ca9163d9
  • 27,283
  • 64
  • 210
  • 413
  • 4
    Seems like view-specific logic. You could translate the conditional parameters (e.g. E>100 & F<0) as model-specific properties (and give them domain-specific names). – Peter Ritchie May 12 '12 at 04:38
  • Agreed, I would place this logic on the view aswell. – Mahn May 12 '12 at 14:34
  • Yeah, translating the conditional parameters into view model properties and making the decision in your domain layer sounds like a good option to me. – dreza May 12 '12 at 21:56

3 Answers3

1

There are several ways to achieve what you are trying to do. You mention the term 'View-Model' a few times in your description, which makes me think you are trying to use the design pattern 'MVVM' (Model-View-ViewModel), which is popular when using WPF or Silverlight technology due to things like it's support for databinding against the view, but can be extended to other technologies too.

In MVVM, the tiers are split into the Model, the View-Model and the View.

The Model is essentially your domain, and is used only for Domain specific modelling. Your applications entities should live here, but there should be no calculations, or manipulation of the domain entities. eg. If it was a cycling domain, your 'Bike' and 'Rider' classes should live here, but there should be no code relating to calculating the race winners, or what colour to display the winner in your application GUI.

The View-Model is where you prepare your domain entities to be presented into your View (User interface). You pretty much achieve this by wrapping your domain entities into new classes, that take the domain object in the constructor, but then expose, or translate the existing properties into the ones you want to be displayed in the View. In the cycling analogy your Bike object might have Make, Model, Cost, RRP, TimeBuilt properties, so in the view model I would expose the Make, Model properties, but then translate the Cost and RRP along with margin to come up with the retail price (as seen on the front end).

The View, as you might have guessed is where this information is displayed. This might be a desktop, mobile or web front end - it doesn't really matter. This is also where any rendering of the UI should be achieved. If I wanted to highlight great deals to my customers, and colour any Bikes with very good retail prices in green - I would do it here.

So, when relating to your example, formatting how the object is displayed should be achieved in the View. Even if your not using MVVM, you can achieve very similar results by extending your domain objects into Wrapper classes to be deployed and manipulated. Your rules such as

Highlight the background of the cell if A is in 'xxx', 'zzz' and B = 0 or D > 200

can be modeled in a boolean on your view model class, giving you the effect you need, without polluting your domain objects with non-specific code.

Regardless of architectural choice, (MVC, MVP, MVVM etc) these are good guidelines to develop by, as they deploy separation of concerns between the layers of your application.

Patrick McCurley
  • 2,006
  • 1
  • 14
  • 24
0

You could store the output of all your 3 calculations as properties on you object, then pass the calculated object to your view.

For example on point 1 render the number if it is negative. this color red could be passed to the view. the actual calculation that determines the color to be red could happen in your biz logic layer.

Please let me know if this helps.

Bull
  • 701
  • 1
  • 6
  • 13
  • Do you mean add a color property for each numeric property? like `class M {string A; int B; Color BColor; float C; Color CColor; int D, Color DColor; .....}`. It seems it will need some boring boilerplate code in the view rending part. – ca9163d9 May 13 '12 at 03:14
0

The term "view model" is wrong. View and Model are two separate things, each dealing with a distinct/separate concern of the application: model encapsulating business logic, view handling presentation/display. In simple terms, model is your domain object. What you have shown in your example, is presentation-related. It belongs to view, not to model.

Nazar Merza
  • 3,365
  • 1
  • 19
  • 19