If there's anything that puzzles me in life is the problem of association, or to put it more simple, how things relate to one another.
You see, everything is or can be related, associated, connected, chained or coupled together. Of course, that is, according to a certain meaning, context, scope, perspective, principle, etc.
Even things that seem so far apart can result being surprisingly closely related: the very well named "Theory of Chaos" (a lot of pun intended here) states that things are connected in such a way that a butterfly flying in Shanghai can cause a storm in New York City.
With regards to this last thought, one could guess that not only things are related, but they are chained in such a way that every relationship ripples to the next, and to the next, and to the next, connecting the dots, and thus creating a kind of balance.
Philosophers often ask themselves:
- How does language relate to reality?
- How does reality relate to different phenomenon?
- How does phenomenon relate to theories?
- How does theories relate to concepts?
- How does concepts relate to language?
- How does language relate to reality?
What is Object Oriented Programming but an ode to relations, connections, and associations? Terms like "class", "inheritance", "polymorphism", "base types", "derived types", "generic", "model", "binding", "pattern", and even "instance", "object" or "singleton" and nothing but indicators of "how" something relates to something else, or why not, to itself.
So knowing "how" to relate "things" is key to write good code, is that it? Well, yes... In part.
Although usually pointless, philosophers do come up with good questions: how does language relate to reality? Understand that now I'm referring to the term "language" as in "programming language". How does a few lines of code describe and solve a real problem in life? Just as we use words to translate whatever our senses present to us: hot, sour, smooth, tall, rank-smelling, can we describe our world, our lives, our reality through a computer program? Again, just as with words: sometimes we can, sometimes we cannot.
Gorgias, a pre-socratic sophist used to say:
1. Nothing exists;
2. Even if something exists, nothing can be known about it; and
3. Even if something can be known about it, knowledge about it can't be communicated to others.
4. Even if it can be communicated, there is no incentive to do so.
Of course you would be tempted to ask him why. And so, he would answer with another question:
"How can anyone communicate the idea of color by means of words since the ear does not hear colors but only sounds?"
Despite all that, there IS a relationship going on there! We might not be perfect at describing it, if we can do that at all, but that doesn't mean that the relationship CAN be made.
So one thing is certain: if you go ahead and try doing it, you should try your best to understand this connection we make in order to solve the dilemma at hand. Back to programming, this means that only when you understand and become aware of the relationship that binds reality to your thinking, and your thinking to your programming skills, and your programming skills to reality, and so forth and so on, only then you will get the most out of yourself. No principle or thumb rule can teach you that.
Well, this essay is actually "related" to a post about a nhibernate mapping model, but since it's taking some time to write, and it sort of became an article on its own, I will leave it as it is and hope you stay tuned for what coming next.
I'll be back!
Code to The People
Programming for the masses.
Tuesday, August 2, 2011
Monday, July 11, 2011
NHibernate cascading styles + ConfOrm = Iguazu Falls!
Alright! So let's get down and dirty with my first "real" blog post, shall we?
For those who don't know about ConfOrm, let me say that he is the smartest guy in town when mapping domain entities is all about (besides Fabio Maulo, of course, who is responsible for it as well as being NHibernate's project leader :-) ).
you can read all about it here:
http://fabiomaulo.blogspot.com/search/label/ConfORM
If there is an ideology hidden in this post, that would be to prove yet again that you can use ConfOrm to "auto-map" almost any mapping scenario you can think of, no matter how complex your scenario is.
I have this domain that has lots and lots and lots of entities that map to a single one. Even this entity maps to itself.
Most of the associations are the same: many-to-one. But as well this domain makes use of a many-to-many, and a peculiar many-to-any association (more on this domain in the following posts).
Irrespective of the association used, all of them share one thing in common: the association's target entity. And even if you don't know the actual mapping, you can guess that if everything points to a single thing, then that thing sort of defines the rules of the game.
Now, while ConfOrm provides many "patterns" to set cascadings based on the association type of a mapping, it does not provide a way to set cascading styles based on given types, more specifically, the target of the association.
That being said, what ConfOrm DOES provide is a way to define your own patterns, and that is what makes it so useful: you define your conventions (plus all the gems in ConfOrm.Shop) and this guy takes care of the rest! You do have to hand-code the "exceptions" to the rules yourself, but that's what they are, exceptions.
So you get the usual "mapping-by-code" benefits that you get with tools like Fluent NHibernate, and your mapping code reduces a lot. But more important than that is that you can make your domain grow without having to revisit over and over again your mappings.
Ok, I just realised that I wrote too much already and didn't show anything to prove what I'm saying! So here you go:
And you can use this pattern like this:
Simple, huh!
Do let me know what you think!
For those who don't know about ConfOrm, let me say that he is the smartest guy in town when mapping domain entities is all about (besides Fabio Maulo, of course, who is responsible for it as well as being NHibernate's project leader :-) ).
you can read all about it here:
http://fabiomaulo.blogspot.com/search/label/ConfORM
If there is an ideology hidden in this post, that would be to prove yet again that you can use ConfOrm to "auto-map" almost any mapping scenario you can think of, no matter how complex your scenario is.
I have this domain that has lots and lots and lots of entities that map to a single one. Even this entity maps to itself.
Most of the associations are the same: many-to-one. But as well this domain makes use of a many-to-many, and a peculiar many-to-any association (more on this domain in the following posts).
Irrespective of the association used, all of them share one thing in common: the association's target entity. And even if you don't know the actual mapping, you can guess that if everything points to a single thing, then that thing sort of defines the rules of the game.
Now, while ConfOrm provides many "patterns" to set cascadings based on the association type of a mapping, it does not provide a way to set cascading styles based on given types, more specifically, the target of the association.
That being said, what ConfOrm DOES provide is a way to define your own patterns, and that is what makes it so useful: you define your conventions (plus all the gems in ConfOrm.Shop) and this guy takes care of the rest! You do have to hand-code the "exceptions" to the rules yourself, but that's what they are, exceptions.
So you get the usual "mapping-by-code" benefits that you get with tools like Fluent NHibernate, and your mapping code reduces a lot. But more important than that is that you can make your domain grow without having to revisit over and over again your mappings.
Ok, I just realised that I wrote too much already and didn't show anything to prove what I'm saying! So here you go:
1: /// <summary>
2: /// Pattern to create a general cascading rule where the target of the
3: /// association is of type T.
4: /// </summary>
5: /// <typeparam name="TMatch">A type to use as a target match.</typeparam>
6: public class DefaultCascadingForTargetPattern<TMatch> :
7: IPatternValueGetter<Relation, Cascade?>
8: {
9:
10: private readonly Cascade _cascade;
11:
12: public DefaultCascadingForTargetPattern(Cascade cascade)
13: {
14:
15: _cascade = cascade;
16:
17: }
18:
19: /// <summary>
20: /// Determines if the target type of a relation (subject.To) matches the
21: /// type TMatch.
22: /// </summary>
23: public bool Match(Relation subject)
24: {
25:
26: return ReferenceEquals(subject.To, typeof(TMatch));
27:
28: }
29:
30: /// <summary>
31: /// Returns the cascading style to be used.
32: /// </summary>
33: public Cascade? Get(Relation subject)
34: {
35:
36: return _cascade;
37:
38: }
39:
40: }
And you can use this pattern like this:
var orm = new ObjectRelationalMapper();
orm.Patterns.Cascades.Add(
new DefaultCascadingForTargetPattern<YourEntityHere>(Cascade.Persist)
);
Simple, huh!
Do let me know what you think!
Hello, World!
Hi out there, wherever you might be.
I'm a man of many words... But only when I speak.
For a long time I considered the idea of starting a blog about coding, but given the previous statement, I held that idea back. That is until today.
If you see this, you will realise that I just needed a push, since a single reply to a comment cannot be the sole cause of taking the time and effort of doing this, can it? Let us hope for the sake of this blog update rate that it is not.
That being said, do not expect to find here long essays explaining the meaning of life using programming patterns, but rather some small snippets and random thoughts that help me get there, or at least make it through the day.
So with no other further delays, let me introduce myself.
My name is Nicolas, I was born and raised in Buenos Aires, Argentina. I'm a programmer who studied philosophy (yes, philosophy, and I dropped out) and even hid my keyboard for almost 4 years while I worked as a cabin crew for an airline company.
I hope my introduction serves as a warning for you to keep in mind, for I may have some ideas that, well... They might seem a bit odd, to say the least. Besides, remember that this statement could produce a false value.
But hey! This is just a blog! It is not the Bible, nor Karl Marx's or Agile's manifesto. So I hope you just relax, enjoy and maybe find my writing to be useful to you some day from now.
I'll be back in a few...
I'm a man of many words... But only when I speak.
For a long time I considered the idea of starting a blog about coding, but given the previous statement, I held that idea back. That is until today.
If you see this, you will realise that I just needed a push, since a single reply to a comment cannot be the sole cause of taking the time and effort of doing this, can it? Let us hope for the sake of this blog update rate that it is not.
That being said, do not expect to find here long essays explaining the meaning of life using programming patterns, but rather some small snippets and random thoughts that help me get there, or at least make it through the day.
So with no other further delays, let me introduce myself.
My name is Nicolas, I was born and raised in Buenos Aires, Argentina. I'm a programmer who studied philosophy (yes, philosophy, and I dropped out) and even hid my keyboard for almost 4 years while I worked as a cabin crew for an airline company.
I hope my introduction serves as a warning for you to keep in mind, for I may have some ideas that, well... They might seem a bit odd, to say the least. Besides, remember that this statement could produce a false value.
bool programmer = (latinAmerican == exPhilosophyStudent == exCabinCrew == canDoAnyCode);
But hey! This is just a blog! It is not the Bible, nor Karl Marx's or Agile's manifesto. So I hope you just relax, enjoy and maybe find my writing to be useful to you some day from now.
I'll be back in a few...
Subscribe to:
Posts (Atom)