ViewModels: make them right!

It’s not so simple to just make a class implement the INotifyPropertyChanged and create some properties.

Normally you have to REPRESENT a model. But how? Replicating the properties in the model that you want? Exposing the model itself using a property?

That is a good question that every MVVM lover should have asked himself when writhing a ViewModel.

You can take a look at this article. It really hits the nail on the head.

http://msdn.microsoft.com/en-us/magazine/ff798279.aspx

I normally expose the model directly and make UI classes that implement INotifyPropertyChanged. But I see the property mapping far more elegant and pure MVVMish 😉

What do you prefer?

Redesigning!

Harrhg! You may be wondering what the hell I’m doing instead of writing new keep on pushing new articles of the series “A Visual Designer the DDD way”.

The reason why this is completely stopped, clogged, bogged are any other words I like to say when I refer to development is because I’m redesigning the model. And of course, this is a task that needs spending some time, something I don’t have these days.

But you can be sure I’m into business! I’ll be back update the class diagram and more really soon!

A visual designer the DDD way. Part 2 REVIEWED!

Woohoo! I’m redesigning the model, so I will have to make some modifications to the previous articles. I think it will lighten up the design a bit 🙂

A visual designer the DDD way. Part 2

As I told you in my previous article, my limited understanding of what DDD is and my most-than-evident passion for the MVVM architectural pattern led me to try a rather unusual way of making a simple visual designer.

First of all, I analyzed my domain. For the moment, it consist of a document that is composed of another level of  “subdocuments”. And those are composed of “simple” items like shapes (rectangles, lines, ellipses and rich text…) and other data-bound items (fields) which you can assign variables from a data schema to dynamically show content (text, generally).

A more advanced feature is that a child document can contain more child documents (a perfect candidate for the Composite pattern). All in all, you have a Main Document with child documents, and each child document can have shapes, “dynamic” content and other child documents.

As you can see, I am focusing on my domain. A very simple domain, for the moment! but I’m not thinking about how to represent it, how to persist it or how to process it. In fact, this picture of the possible relationships between each element is what will give us a great level of abstraction and freedom.

This is the class diagram I got. I think you can get the idea behind it.

To continue…