NHibernate Forge
The official new home for the NHibernate community
NHibernate blog » Architecture Diagram Rework

Architecture Diagram Rework

While working on the NHibernate Documentation, I’m drawing some pretty pictures. I actually never liked the architecture diagrams much, because I never knew what exactly they are trying to show.

The original architecture diagram looks like this:

image

I never found this diagram very helpful. (When I started learning NH, Transient Objects and Persistent Objects were very confusing to me. Are this different classes?)

So I decided to rework it. I ended up with something that is not very different from the existing diagrams so:

New Architecture Diagram

I shouldn’t cover all the little details of the NHibernate’s internal design, just the concepts that are visible to the user.

What do you think: is this kind of useful?

Posted jun 04 2009, 02:34 p.m. by Stefan Steinegger
Filed under:

Comments

Raul Carlomagno wrote re: Architecture Diagram Rework
on 06-04-2009 12:09

very useful diagram, but just a detail to consider if you want, what about using office's 2007 diagrams? they are visually richer

keep on with this project, it was necessary

if you need some help, i wish to collaborate

cbolyard wrote re: Architecture Diagram Rework
on 06-04-2009 13:27

Very nice!

Fred Morrison wrote re: Architecture Diagram Rework
on 06-04-2009 13:34

Your new diagram is much more understandable, but I'm fairly new to NH, so take that for what it's worth.

Simon Martin wrote re: Architecture Diagram Rework
on 06-04-2009 13:54

I'm also quite new to NH but the new diagram is easier, for me, to understand too

Dario Quintana wrote re: Architecture Diagram Rework
on 06-04-2009 15:39

The 'Business Logic' could lead to confusion since 'cause there is only one book to design the model of our application. With an square that says: 'Objects Model' OR 'Model' is ok.

BTW, where are the Transients and Persistent objects ? Also we need maybe to mention to the Detached objects

Stefan Steinegger wrote re: Architecture Diagram Rework
on 06-04-2009 17:28

@Dario: I'm not sure if I understand what you mean with "only one book to design the model". The Business Model are the entities that are mapped, the Business Logic are services or other classes that implement the logic.

I actually skipped the Transient and Persistent Objects by purpose, for me it was very confusing. And - as you say - not complete, because there are also Detached Objects. But these are object states, IMO this is not part of an architecture diagram. The business objects don't care about their persistency state.

@rcarlomagno: There are actually three reasons why I wouldn't use office 2007: 1) I don't have it 2) others don't have it and contributing on open source software should be for free :-) 3) With "visually richer" you probably mean "glossy 3d buttons". I don't like glossy 3d buttons. Everyone has glossy 3d buttons. It's like chocolate for breakfast, for lunch and for dinner. I mean, I'm swiss after all, but too much chocolate doesn't make me happier.

And, yes, I need help and your collaboration would be much appreciated. For the moment, I'm building up the structure and getting feedback from the community like this, but later I will need some people for different tasks. I will collection some Email addresses until then and contact everyone that wants to help.

Chorn Sokun wrote re: Architecture Diagram Rework
on 06-04-2009 22:40

Stefen, what the diff between DB Driver box & ADO.NET? Where all the ODBC & OLEDB gone?

Stefan Steinegger wrote re: Architecture Diagram Rework
on 06-05-2009 3:35

@Chorn: The DB Driver is the NHibernate driver which can be configured. ODBC and OLEDB is gone to the not-important-enough-heaven. Again: I didn't try to draw the same picture with more colors, I tried to draw a new picture. Do you think ODBC and OLEDB are important to be mentioned?

Dario Quintana wrote re: Architecture Diagram Rework
on 06-05-2009 14:30

Hi Stefan,

NHibernate doesn't talks in this language: "Business Object" "Business Logic".

The NH language is talked with Persistent, Detached and Transient entities.

The phrase: "only one book to design the model" was wrong: I meant "thereisn't one only book to design the model", sorry about that. Talking about "Business Objects" and "Business Logic" seems you following one book. I know what you mean by using those therms, but you are saying nothing.

Imagine that later came a DDD guy and make another diagram, how suppose the diagram should look like?

Doesn't matter if the terms  Persistent, Detached and Transient entities cause confusion, they ARE very important concepts and shoudn't be removed. If they cause confusion, must re-read them again and again.

Cheers

Stefan Steinegger wrote re: Architecture Diagram Rework
on 06-06-2009 3:52

Hm, of course I don't want to talk about a certain architecture approach. But to me, Business Objects and Business Logic are very common terms, and also fit to DDD approaches. I tried to show a common application that is NOT influenced by NH. If I would use NH terms in the application layer, it seems as if the application design would highly depend on NH, as if one had to write specific classes ("Persistent Objects" for instance) only for NH. This is not true, it's misleading and confusing.

See en.wikipedia.org/.../Business_object_(computer_science)

and en.wikipedia.org/.../Business_logic

If you know better, more common and neutral terms, I'd use them.

The object states ARE very important, but not for the architecture. They are shown in a different diagram and explained separately in detail. I can't show terms from different dimensions in the same diagram.

benhyrman wrote re: Architecture Diagram Rework
on 06-09-2009 10:09

I like it. Understanding transient, persistent, and detached objects are important, but not necessarily from an architectural view. Rather, they're states of an object in it's relation to (or lack of relation with) the Session.

While Business Logic and Business Model are the correct term, they suffer from SemanticDiffusion (martinfowler.com/bliki/SemanticDiffusion.html). Maybe just call it Logic, Model.

Also, while someone should understand O/R by this point, would it be cleaner to call those NHibernate Mapping Files? Calling them O/R mapping files implies a certain generic flavor of the implementation while it's actually a function of the ORM's needs (ORMs don't use the same maps, not all ORMs need maps)

Stefan Steinegger wrote re: Architecture Diagram Rework
on 06-10-2009 5:25

@benhyrman: Thanks for your feedback. Logic and Model might be fine.

I agree with the NHibernate Mapping Files, but I actually also don't like the term "files" there. It should be rather a "NHibernate Mapping Definition" or something. On the other hand, "files" sounds familiar and friendlier.

benhyrman wrote re: Architecture Diagram Rework
on 06-10-2009 23:41

Well, how about NHibernate Maps or NHibernate Mappings or well, I'll think about it some more

I think it's a great step forward even as-is.

Powered by Community Server (Commercial Edition), by Telligent Systems