This is not an obituary for object oriented programming, nor do I think that I have to write one any time soon. This is a post to rally the fanatics, the converted and the blessed to do something about the state of OOP in our community.

At Developer Summit last year Joakim Sundén talked about the ethics in our line of business, or rather the lack there of, and how there is a vast amount of developers that just don't care about the quality of their code. With arguments like "I don't have time to do OOP" or "OOP looks good on paper but in real life it won't work" is not uncommon and are  tightly coupled with solutions built on transaction scripts and huge methods (and often in companion with the same arguments coupled with other trade skills like documentation, tests and basic software engineer practices).

My feeling is that the "I don't have time to do OOP" really means "I don't have time to learn OOP" and this is even more serious. The moment we as developers stop perfecting our skills, that's the moment where the industry is in danger and the moment where the industry starts accepting bad quality, expensive maintenance and code that's disconnected from the business. Should we take this? Should we let the laziness of some developers set a mark of shame for the whole trade?

I for sure won't!

It's time to rally resistance against these lazy developers, rally against their unwillingness to perfect their skill in the trade, rally against ludicrous arguments that in some circles are treated as, and sold to clients, as truths.

I call upon the developers that think that the trade is worth a better faith to start to meet this cancer wherever it shows it's ugly face. It's to easy to sigh and say "they just don't get it and I don't have the time nor energy to make them". Stop, make your voices heard, take your responsibility for the over all view of our trade.

And Remember:

"All that is required for the triumph of evil, is for good people to remain silent and do nothing"

Now go out and evangelize, strike down wherever evil surfaces and make damn sure that ethics, long-term quality and the willingness to perfect ones skills will be the ruling mentality in our line of trade.

Do not stay silent!

The last couple of months I've been in several positions where I've had the opportunity to talk to a lot people and express my point of view on things. I base my position on discussions with other people, theory, experiments and past experiences from projects. More then once now I've heard those view points come back to me in through back channels where they've taken wide loops and gotten somewhat twisted. It?s funny how people pick up the small details and  nuances in the way you express those opinions and base the experience of the whole talk on those. It's funny because I didn?t think much of it when I said it and I was really focusing on giving another message.

This makes me think.

I've done several hours of presentation training, weeks of pedagogic training and years invested in helping people understand technology. But all this time  I've been focusing on the the message I've tried to communicate, never reflecting over that what's a big picture for me might be a small picture for some one else and what I consider a simple detail might turn up as a big picture for another developer.

It surely makes me think.

Even with all this communication training I still seem to miss the target sometimes when formulating and delivering a message I want to share. What's even worse, that message get's distorted through filtering and "value" is added based on someone else's background and opinions.

Communication is really, really hard.

I think I've finished thinking and ready to take action.

From now on I'll be a little more careful on the messages I send out and I will try to explain all my view points in detail on this blog. This will make sure that there will always be a solid written source to refer to and if my opinions get twisted you know where to find the original.

I'll start of by explaining where my position on stored procedures come from. Why my default architecture and design lacks stored procedures and why I feel that the projects I build is much healthier without them.

Oh and yes, my opinions are my opinions if I don't reference someone else I'm not speaking for them in any message I'm giving.

I don't know if anyone missed the great push Microsoft is doing towards moving their data access stack towards a more O/R-mapping kind of solution. LINQ is part of that but also the implementations of LINQ to SQL and the latest addition the Entity Framework.

Danny Simmons, a PM on the ADO.NET team, posted earlier this week about where in the software puzzle the Entity Framework fits.

You can read his views on the matter over here: http://blogs.msdn.com/dsimmons/archive/2008/05/17/why-use-the-entity-framework.aspx 

The last section of that post has stirred up quite some emotions in the .NET community and I can agree with some of the objections that have been raised, yes EF is still intrusive and yes it's data centric rather then domain centric.

But come on,  would you rather that Microsoft continues down the Typed Dataset path? EF is in V1 (or well, sort of) and the team is still learning the basic principles around ORM and Domain Centric applications. Most of them have lived in the world where SQL server has been dominant. I'm just really glad that they've woken up out of the Data-centric world and have seen that there is actually a lot of other challenges around building applications that's not about storing data in a database.

I'm certain that if we continue to give valuable, sensible and sane feedback the team will continue to develop the framework in the right direction.

I also think that the effort they are doing is great, it will make the .NET community more mature when it comes to OO principles and it will drive .NET developers to start think about application/domain based views of their information. I've already gotten a lot of customers that are interested in learning ORM, some starts out by wanting to learn about EF and stays there, for some EF is an eye opener and they move on to frameworks like NHibernate et al.

This is a good thing, as in every market Microsoft heads in to, the total market share will increase.

Btw, on the note to re-use the conceptual model everywhere, One Model To Rule Them all: https://lowendahl.net/showShout.aspx?id=203

--

More links on the current EF debate:

Frans's reactions: http://weblogs.asp.net/fbouma/archive/2008/05/19/why-use-the-entity-framework-yeah-why-exactly.aspx

Jeremy Millers reactions: http://codebetter.com/blogs/jeremy.miller/archive/2008/05/19/what-dan-simmons-forgot-to-tell-you-about-the-entity-framework.aspx

Greg Young's reactions: http://codebetter.com/blogs/gregyoung/archive/2008/05/19/ef-long-term-plans.aspx

Julie's reactions: http://www.thedatafarm.com/blog/2008/05/20/ResponsesToDannySimmonsQuotWhyEntityFrameworkquotPost.aspx

Sorry for the political statement but I just can't stand the kind of regime that can shoot down un-armed monks because of a different point of view.

We should drag the generals out of the jungle and let them get the peoples judgment. Guns are not a valid poll method in any argument so just string 'em up somewhere. I'm not really sure they will smirk as much when they don't have tanks between them and the people they suppress.

And remember "All that is required for the triumph of evil, is for good people to remain silent and do nothing"

My latest addition to the blogging world was received with mixed feelings. The general idea of that post and the code that came along with it was to make it easier to work with "ad-hoc" queries in your code. The discussion in the comments was not so much about my proposed solution for handling ad-hoc queries as it was about sprocs vs ad-hoc. This is a really old debate, kind of the "el classico" of data access but I would like to elaborate on some of the comments and explain what motivates me to avoid sprocs as long as possible.

Read more here https://lowendahl.net/showShout.aspx?id=140

In some of the comments, sprocs are looked at as a single point of integration. The scenario is that multiple applications should access the same data and do so through the same sprocs. The argument is that this will enable re-use and add the ability to make changes that affect all applications that uses the sproc.

"Bob" comments that:

"an added benefit of SPs is that they provide a centralized, unified view to the data. When business rules change, they only have to change in one place -- the SP"

I can understand that in legacy systems, heck I'm even a father to a couple of those, sprocs was the single point of integration and really the only way to share rules and data access cross-platform and cross-applications. But it was a long time ago that we really could count those solutions as any kind of best practice. In 2007 reuse of rules and processes is best enabled by a SOA.

There is also other things with having rules and process expressed inside sprocs that bothers me. First of all SQL is really not a language that excels in describing and enforcing business rules. It was created to be effective for CRUD, SET based operations, and not to capture business intent. Languages like C#, Java and Ruby are much better at that.

Secondly testability goes out the window the moment I start to write my complex price calculations in SQL, there is just not enough support to do isolated unit testing on single sprocs without directly hitting "integration testing". Whereas application languages and frameworks have extensive support.

Tests are a key component in successfully changing any business rules that are already in production. Without them, you will just not know what you broke until it is to late, with hours of debugging, fixing and work around as a result.

These two areas are enough to make me keep any kind of business knowledge in SQL but there is a lot of others that count to, such as:

* The implicit constraint on scalability that Evan Hoff wrote a nice summary about over here: http://www.evanhoff.com/archive/2007/06/05/19.aspx .

* The inability to create flexible queries with where clauses, order by, group by etc that are based on decisions made by the application.

* The static way which they are pre-compiled, which lures people into "performance" traps only solved with the "with recompile" (for sql server) flag on a sproc call, effectively re-rendering the query plan anyway.

* The fact that SQL is just plain ugly and hard to maintain when you get to a certain number of LOC.

* As Mats pointed out in the comments here of the previous post: Try to version sprocs and the dependency between them, you will certainly die of old age before you figure it out.

These are the reasons why I stay away from sprocs.

There are reasons when I might want them, like for granular security (as OJ mentions).

Or.. ehm.. Problem is, I don't (like Phil also commented in the post) like to handle my users / groups in the database. I want every application / service to have it's account and throttle all queries through there. That gives me the same security context, which effectively allows me to use the built in Connection Pooling. Additionally I get the benefit of administrating access for applications and don't have to worry about 100's of roles or 1000's of users.

So no, there is probably nothing that would make me use sprocs (well a gun to my head or a million dollars aside)

I've been working a lot with WCF lately and yesterday when I was testing different authorization solutions I just came to realize.

CAS uses AOPish like interception as well.

Look at this CAS policy:

[PrincipalPermissionAttribute(SecurityAction.Demand, Name="Bob",Role="Supervisor")]

This is pasted on a method or a class to tell CAS who can access the given method / class. The hilarious thing about it is that this is the recommended approach instead of explicitly use principal permissions in the method code to "decouple the security requirements from the actual method code".

Now, you don't have to be an AOP guru to see the similarities between AOP interception practices of decoupling "cross cutting concerns" and what CAS uses to "decouple the security requirements"

It would be very interesting to hear MS argue themselves out of this one. "Interception is not something we want to support, except for the central security model in the CLR then it's OK"

Somehow the first post is bugged, I'll just repost it here.

Every now and then Microsoft and other vendors releases a new initiative that will be the abstraction level that will be the "one abstraction level to rule them all".

The latest addition is the Software Factories push where, among others, the PAG team is building slick factories like the WCF Factory and CAB block to automate certain tasks when building applications.

Just around the corner is a new such factory, the Acropolis product. When Ayende saw that, he wrote a blogg post that I think was right on the spot. He criticizes some of the pushes for the "no code approaches" as  being an attempt to run away from code.

I have to agree with him on this. Almost every push to automate stuff is with the promise of "no code" or at least "less code". Once in a while it also bundles with a promise of "including the domain experts in the implementation". Yeah, let's do that. Let's go back to when the accounting staff, that was skilled in Spreadsheets, designed and built advanced enterprise type of applications, that went really well then.

I'm seeing two kinds of problems with this approach they are both related but I will try to explain them separate.

The first problem is usually around people who don't code. Just a week or so ago I was called into a meeting where I was asked to do a quick estimate on the effort to move an application from excel to the web, from a stand alone spreadsheet to a collaboration tool. When I explained what kind of ballpark we where talking about, they where silent for a moment and then someone commented "but I can add most of this logic in excel in a day or two". In a sense she was right, it would be quick to come half-way in excel, but in another she was wrong. Excel is an application with million rows of code that already abstracts away most of the complexity of the task at hand and what they wanted was an application that mimicked some of excels features but without some of the constraints of excel.

Basically the abstraction level Excel offers have hid away the complexity and makes stuff easier, but it also gives a false sense of simplicity. Excel makes complex tasks seem simple, but Excel is still a complex application.

The other problem with having a false sense of simplicity based on a high abstraction level was very well argued for at this years Developer Summit (http://www.cornerstone.se/expertzone/dev07/) by Eric Dörnenburg from Thoughtworks (http://erik.doernenburg.com/). He was talking about "How simple is to simple" and one of the points he brought up has the same flavor as the excel one but targeted at developers.

When DCOM arrived it had the promise to do distributed applications simple as newing up an object. DCOM hid away the communication and the complexity of remote objects and the developer using the object had really no way of knowing if that object was local or not. Very much so in VB6 development a little less so in C++. The idea was to register a proxy that looked like a local object and acted like a local object. Now if both those are true, a lot of developers will assume it works like a local object as well (If it walks like a duck ...).

The problem, Eric pointed out, was that the complex task of distributing objects was hid away by the abstraction level and made people write bad software not taking in account that there was a wire in between them and the real object, which in the end resulted in chatty interfaces and problems with scalability and/or performance.

I am not saying that abstractions are a bad thing, just that they have to be very carefully created and implemented. In the DCOM case, Microsoft came to their senses and created WCF, which also is an abstraction layer. But the abstraction is the communication it self. It's easy to communicate but you are very much aware that you are communicating. Some of the complex stuff is invisible others, where problems could arise, are very visible.

Finding the right abstraction level is a tedious task, it is not simple, and in many cases it is the developer version of "the search for the holy graal", only for us it is "the search for the holy abstraction level".

For a couple of days there has been an ongoing debate about ORM (or rather DDD/Object Orientation) vs DB Centric applications.

There has been numerous posts and comments on Ayendes blog and the guy who started it Rob Conery (of SubSonic fame).

The debate is long and I recommend you to start here: http://ayende.com/Blog/archive/2007/06/05/As-an-ORM-Person.aspx and just follow the discussion.

During this debate, Evan Hoff has written a really good post summarizing some of the problems with putting to much "heavy lifting" in the DB layer. He makes a really good case and presents some really good points.

Whiter or not you like Sprocs you should really read this: http://www.evanhoff.com/archive/2007/06/05/19.aspx

A couple of times I've been discussing adding AOP features to C# or the CLR. Most of thees discussions has been with members of the C# team but also with Ed formerly on the PAG team.

The basis of Microsoft's objection to Aspects has always been that injecting behavior based on some kind of configuration is confusing and does not give a clear picture of what the result of the code you are looking at would be. Since aspects could or could not be applied, there is no way for you anticipate the exact behavior. This is a fair point to make, and very real.

A similar point was made about polymorphism and virtual methods back in the days, where allowing overrides of methods could dramatically change how the code behaved and thus not make it clear exactly what happens when calling that method.

Today we just don't care anymore, we have even named the "not knowing" with a pattern name; "Template Method".

Much like polymorphism has come to play a very important role in the design and implementation of software today, I feel that aspects are moving to wards filling an equally important role. The idea of reusing cross cutting concerns and by configuration apply them to different parts of my software is very appealing.

This will allow me, for example, to create a centralized caching mechanism which I could choose to apply or not apply to certain methods by configuration. The code in the method is itself not interested in whiter or not it gets cached but I would get the ability to apply it where I see fit, without touching the code. Taking the caching example further I could have some methods utilizing the cache, while others would flush it. Like GetOrder / UpdateOrder. Get might be cached and Update might flush that cache (now let's not get into the pitfalls with caching, this is about cross cutting concerns).

For me aspects is the natural evolution of object orientation and the single responsibility principle. It allows me to really separate my software into reusable parts where I can add and remove behaviors as I go.

Microsoft's story around this is interesting. Aspects really need a good mechanism for interception. Where it has to be possible to intercept method calls and react to them before or after they are called. Going back to the argument that "There will be hidden code that executes", let's look back in history for a while.

When Microsoft built MTS and COM+ they realized that to be able to make any method transactional they had to have some kind of mechanism to intercept a method call, start the transaction and then execute the method. How did they implement this? They used proxies  that could intercept just about anything and apply CROSS CUTTING CONCERNS (like transactions) on the COM+/MTS objects. So product teams at Microsoft has successfully walked the path of interception. In one sense COM+/MTS used the idea behind aspects to accomplish what they had in mind.

Remoting had a similar story, where our objects got intercepted by the remoting framework and funky stuff happens by itself in the call chain (where we actually could add our own interceptions).

Building frameworks and containers is one thing where aspects really excel. The frameworks can apply their functionality on top of what ever the user of the framework is building and the user don't have to think to much about it. One such example is dirty tracking of the objects. Using aspects and applying dirty tracking to every setter, we don't have to write code like this:

public string Name {
 get { ... }
        set {
            _name = value;
     FlagDirty("Name");
        }
}

Over and over and over and over again in our code. It could simply be applied by the framework as an aspect that stated "When a property gets set, mark that object/property dirty".

There is numerous of other scenarios where intercepting and adding behavior is important.

Now building some advanced frameworks of their own where they will apply functionality on users code, Microsoft have come to realize that having points of interception where stuff can be added is very useful. The remoting and COM+ approach proves that.

Since aspects are a plague, they now have come up with yet another idea of how to apply these interception points. They called them "partial methods".

Partial methods will allow their framework (which relies heavily on generating code instead of having the code centralized and applied in runtime) to put in interception points in the code, that may or may not be applied.

Using partial methods the dirty example might look like this:

public partial class Person {

   public partial void SetDirty(string propertyName);

   public string Name {
     get { ... }
     set {
         _name = value;
         SetDirty(propertyName);
     }
   }
}

Now if we do nothing, the compiler will simply remove that method call as if it was not there. If on the other hand we add an implementation:

public partial class Person {
  public partial void SetDirty(string propertyName) {
     IsDirty=true;
  }

}

The method now instead gets called.

Ayende (http://www.ayende.com/Blog/) has talked about this and Matt Warren (http://blogs.msdn.com/mattwar/) answered in the comments that "this feature is added to allow code generators to expose interception points".

So instead of creating a mechanism that would allow for interception so others had more support of building frameworks like remoting or containers like com+, they bloat the language with features to support their code generation tools. Now I might be out on a limb here but; WHY?

Creating features in the language to support a specific scenario seems like a waste of resources. If the instead put down resources on creating a generic way of doing interception, support a gadzillion more scenarios which the generator might not have thought of. I could apply interceptions to the generated code that would be special for my scenario, and by configuration at best.

The PAG team has made a real effort here though, they have created the Policy Injection framework which is kind of a V1 of an AOP framework from Microsoft. It relies on the same mechanism as Remoting does, which is kind of killing mosquito's with a bazooka.

What I would like to see from Microsoft though is not the ultimate AOP framework, but constructs in the CLR that would allow for others to build thees kind of frameworks or at the minimum not create constraints that makes it harder.

So, Microsoft, please consider adding support for interception scenarios so that we too can build framework and containers that do funky stuff and stop bloating the language with TOOL specific features.

Microsoft has a history of taking great stuff, re-polish it a bit and then throw it out in the wild as something new or at least re-wamped. Now they just did it again.

Tom Hollander and Ed Jezierski posted a couple of days ago about the new application block added to Enterprise Library 3.0: Policy Injection. Looking at both their posts; they are describing it as a way to separate Cross Cutting Concerns out of your code and make those concerns manageable by configuration. I am really all for separating concerns, especially the cross cutting ones so seeing Microsoft's Pattern and Practices team taking a step in this direction is really commendable.

There is one thing though, they are not calling it what it is.

Looking at the specifications and explanations in these two posts, it becomes very clear that it is nothing but a first attempt on a framework for Aspect Oriented Programming. Ed even speaks about this in his post:

"Why don't you call this AOP? If you know about AOP, you can see where it is similar and where it differs from AOP solutions out there"

"However the reality is most of our customers have not heard of AOP or AOSD. Please put yourself in their shoes for a second. We wanted a name that was reflective of the use and benefit the block brings, rather than using an unfamiliar term that only the exceptions understand"

"We also wanted to have no implicit expectations on the design that may be inherited from AO solutions"

So Ed acknowledges the similarity to AOP but in the same breath he says that it is too hard for customers so see where they can benefit from the technique. He justifies this with avoiding "using an unfamiliar term", now I might be out on a limb here but, the name will not be the problem when trying to make people get it. If anything it will be more confusing and we will have to answer questions like "How does AOP differ from PIAB" or "How does PIAB differ from AOP". The obvious answer will be, "Nothing really, Microsoft just chosed to give it a different name".

No the challenge will not be in the name, it will be in another common AOP question:

 "This is all very scary. I can't know what will happen by looking at the code!"

It is in this objection the real education effort lays, to teach people how to separate concerns and being comfortable with it. For this challenge, changing the name to something more "user friendly" is just creating an unnecessary diversion.

If the PAG team just called it what it is, they could point out to countless books, articles, implementations and communities (like the huge Java AOP community) and say "hey look over here, there is loads of people benefitting and using this technique already. Why don't you join them?".

I do not think they will change it though, because of their second objection. They don't want to be compared to any AOP frameworks already developed and matured. This is a first version framework and I have not seen the code, but I know by experience how first version of anything usually looks and work. But I just have remark for you guys, "courage" instead of "prestige". Dare to put your head out in the open; no one will cut it off for not getting everything right the first time. On the contrary, I'm positive that you will get standing ovations for actually daring to create a MS branded AOP framework.

A final note, I really like this effort from the PAG team. Although I do not agree with all their decisions and implementations choices, it is really good to finally see someone from Microsoft acting in this area even with this kind of small steps.

Links to Ed's and Tom's posts:
http://blogs.msdn.com/edjez/archive/2007/02/23/policy-injection-app-block-behind-the-scenes.aspx

http://blogs.msdn.com/tomholl/archive/2007/02/23/announcing-the-policy-injection-application-block.aspx