Quote of the Day

 

Good to Great by Jim Collins

...the purpose of bureaucracy is to compensate for incompetence and lack of discipline -- a problem that largely goes away if you have the right people in the first place. Most companies build their bureaucratic rules to manage the small percentage of wrong people on the bus, which in turn drives away the right people on the bus, which then increases the percentage of wrong people on the bus, which increases the need for more bureaucracy to compensate for incompetence and lack of discipline, which further drives the right people away, and so forth

Active Record vs Objects

Robert C. Martin (Uncle Bob) wrote an interesting article about Active Record and objects. I do admit that he is partially right but I don't agree with him fully.

Martin Fowler's definition of Active Record is

An object that wraps a record in a database table or view, encapsulates the database access, and adds domain logic on that data.

Uncle Bob wrote

The problem is that Active Records are data structures. Putting business rule methods in them doesn’t turn them into true objects. In the end, the algorithms that employ Active Records are vulnerable to changes in schema, and changes in type. They are not immune to changes in type, the way algorithms that use objects are.

The fact that Active Record is based on database structures does not make it any less object-oriented. Active Record does not even try to solve the impedance mismatch between databases and objects. A full-blown ORM-tool should be able to solve the discrepancy. I don't see Active Record as an object-relational mapper at all. Ok, you can always say it's 1:1 mapper and it's hard to argue against that.

It has “hidden” data, and exposed behavior. I put the word “hidden” in quotes because the data is, in fact, not hidden. Almost all ActiveRecord derivatives export the database columns through accessors and mutators. Indeed, the Active Record is meant to be used like a data structure.

Active Record does not imply that data is exposed directly and this is the first time I've heard that AR is meant to be used like a data structure.  Most of the AR-frameworks just are a bit liberal on data visibility but so are also many ORM-tools.

Applications should be designed and structured around objects, not data structures. Those objects should expose business behaviors, and hide any vestige of the database. The fact that we have Employee tables in the database, does not mean that we must have Employee classes in the application proper. We may have Active Records that hold Employee rows in the database interface layer, but by the time that information gets to the application, it may be in very different kinds of objects. 

Active Record couples the object design to the database design. I don't see it as a problem. It's a design choice. In many cases it's totally acceptable approach. But if the business logic is complex or you want to use for example inheritance, the design gets messy quite soon. That will lead you to for example Data Mappers and full-blown ORM-tools. 

Hi, My name is Tapio, and I write crappy code.

 

It's been more than a day since a wrote crappy code. Today i didn't. I didn't write a single line of code. I know, I know, it's only an excuse. At 5 PM I almost slipped.  Tomorrow will be a difficult day. How can I avoid slipping?  Maybe I shouldn't write any new code. Just do some simple refactorings. We'll see.

While acknowledging you're a Terrible Programmer may be necessary to becoming a Great Programmer, it's not sufficient.

Thanks to Marc, Ted and Udi. Great posts. Atleast now I know, I'm not alone. 

This has not happened before

 

This can't be happening to me. The system will be in production in two weeks. No panic, no emergency meetings, not even acceptance test defects anymore. We must have forgotten something really important. This has to be a dream. Things like this don't happen in real world. Did we do something differently? Not really. Maybe we paid more attention to testing. It helped a lot but it alone didn't cause this. The most important thing was our team. It's nice to have a bunch of smart people working in the same team. Smart people are not afraid of asking questions. If they have opinions they usually are willing to share them. Good communication gives us a better chance to spot problems in our design and find better solutions. Little by little everybody understands how the system works and how different parts of the system work together.  The system might get a chance to succeed.

Linus Torvalds on Git

Would you like to use this kind of features in your .Net development environment?

 

Anonymous methods and maintainability

Anonymous methods are a cool language feature in C# 2.0. I'm not a big fan of using them but they are certainly useful in many scenarios. After reading some articles (here, here, here and here) I realized that even if you can write very elegant code using them, there is a real danger hiding behind the corner. The code might seem clear and obvious but subtle differences can have a huge effect on behavior. This is not always a problem but in some cases it will be. Somebody else will have to maintain your code. If the new guy is not aware of all those subtleties he will have hard time maintaining your code. A small change could break your code and it might be very difficult to find out why it's broken. Keep those unit tests up to date. Without them you are asking for trouble.  

 

Technorati Tags: .NET

Thread Local: A Convenient Abomination.

A couple of weeks ago i tried to find a storage place for sessioncontext(s)  so that one WinForms application could have multiple sessions open at a time. I noticed that there are no easy solutions for that problem. Today i read an article that describes the other side of the coin.

Thirteen years ago, while working on my first book, Jim Coplien and I were having a debate on the nature of threads and objects. He made a clarifying statement that has stuck with me since. He said: “An object is an abstraction of function. A thread is an abstraction of schedule.”

It has become the norm, in Java applications, to assume that there is a one-to-one correspondence between a thread, and a unit-of-work. This appears to make sense since every Servlet request has it’s own particular thread. Framework authors have built on this assumption by putting unit-of-work related information (e.g. session) into ThreadLocal variables.

Clearly, the more ThreadLocal variables that hold unit-of-work related information, the more that the thread and the unit-of-work are related. While very convenient, the basic assumption is dead wrong.

It doesn't matter if you have 1 or 10 threads. The problem is always the same. UnitOfWork or SessionState should have a place that does not depend on threads. It's a dangerous assumption that UnitOfWork is directly related to one single thread. That assumption seriously limits your other architectural choices. 

So, though convenient, ThreadLocal variables confuse the issue of separating function from schedule. They tempt us to couple function and schedule together. This is unfortunate since the correspondence of function and schedule is weak and accidental.

What we’d really like is to be able to create UnitOfWorkLocal variables.

Couldn't agree more.

 

Technorati Tags: WinForms