.NET Architecture & Development

This is my favorite model pattern for designing an application architecture, probably that will be no surprise to you.

In my view Entity represents the data model.

It doesn’t matter if you are talking about business entities or database tables. Both are representations of the data model.

There is some debate on the nature of Entities, should they be active or passive. An active Entity has its own operations, an passive Entity lacks them. This is where the Controller comes in. A Controller is fully equipped with operations necessary for handling of Entities.

An Interface can be an user interface, service interface or a view.

In contrast to one might believe, the important part of an use-case is text, text, text and even more text.

The core of use-casing (nice word) is story-telling. The story of an actor (mostly a Silly User) using the proposed system.

But if that is really the case, why is it useful to draw an use-case diagram?

First, it structures your use-cases as an overview for the reader. Second, by drawing the diagram it structures your thoughts and forces you to focus on the user using the system.

That is probably the most important part of use-cases.

If you want to master the art of model-driven code generation, an essential thing you need is a model of some kind. Maybe you are in desperate need of Kate Moss, but that’s not the kind of model I talking about. I mean some kind of data model.

Preferably, you describe your model in UML. But that is not essential.

As far as I am concerned, you can write it down in notepad, if you like.

My model contains students. Students are member of a certain class, for example a class named Class 3a. A typical class consists of many students, but a student can only be part of one class. The students attend many different courses and a course can have many students.

This data model translates to database tables and relations. In this case you have a table Student, Class and Course. Student has a 1-to-many relationship with Class and a many-to-many relationship with Course.

If you created this database and then extracted a database model from the database, it would look like this:

This would be a physical data model. A drawback of a physical model is that there is no proper way to show a many-to-many relationship. A join table StudentCourse is needed to show such a relationship. In fact it is a pattern to create a many-to-many join in a table.

In UML it looks like this:

And this is really all there is to create an UML class diagram.