+972 52-548-6969
Kobe – Architectural Overview
Sometimes, you have to make a distinction between the system architecture and the system implementation. It is possible to have a great architecture and have the implementers butcher it by not paying attention at some points.
Sometimes, the problem in the code implementation is so bad that it becomes an architectural problem. Kobe is one such example.
We can start with the pervasive Primitive obsession that is all over the map. The common use of “string thisIsReallyGuid”, Copy & paste programming, horrible Exception Handling and total lack of respect for the fundamentals of OO.
All of those tie back together to the lack of architectural oversight over the project. I have the feeling that at no point someone stopped and said: “there has got to be a better way of doing this.”
DRY is a true principle in development, it transcend programming languages and paradigms, about the only one that I can think of that does so. If you violate DRY, you are in for a world of trouble, sooner than later.
SOLID is a set of principles used to build good OO applications. If you are using OO language and paradigms and fail to pay attention to SOLID, it will hurt you at some point. Not as soon as if you have violated DRY, but soon enough.
8.5% of Kobe is copy & pasted code. And that is with the sensitivity dialed high, if we set the threshold to 3, which is what I commonly do, is goes up to 12.5%. A lot of the duplicated code relates to exception handling and caching. Those are classic cases for using an aspect to handle cross cutting concerns. That would reduce a lot of the duplicated code.
The other problems that I have with Kobe is its total lack of respect for SOLID principles. You know what, let us throw solid out the window, I am going to focus on a single principle, Single Responsibility Principle. Just about any method that you care to name does more than one thing, in many cases, they do a lot more than one thing.
This is absolutely wrong.
The “repositories” in Kobe has so many responsibilities that they are just shy of having a singularity around them.
Overall, Kobe feels very amaturish, as if it was written without true understanding of what is expected of quality code, and without really understanding the underlying platform, frameworks or the infrastructure that they are using.
I don’t like it at all, and it is a horrible sample application. In my considered opinioned, it should be pulled from the site, rewritten, and only then published again.
Comments
Maybe it's time for a Rhino-Mvc sample ;-) with all the Rhino components in it..
ps. i agree with your comments on Kobe..
Marco,
Who is going to pay for the time to build it?
Maybe Microsoft should instead of releasing stuff like Kobe.
Does Microsoft have more of these bad written sample applications? I often hear that they saw 'some' practice in a Microsoft application. Personally I find the asp.net MVC a good example how code should look like. It's stays very close to the SOLID principle.
Maybe someone should start a sample blacklist. A list of applications beginners should avoid.
That's hillarious :). I think Ayende you can get paid by Microsoft. I somehow feel that Microsoft is paying people to write reference apps. This can't be a Microsoft team's work. If it is, it says a lot about team they have.
How much do you need? I'd donate as newbies coming to the mvc, tdd, orm, bdd, etc, etc arena are facing an ever-increasing mountain to climb that's getting harder to distinguish between what to follow, what's up to date and what's just plain rubbish.
Programming is a form of art or craftmanship where individual skills and creativity matter the most. Corporations employ mediocre specialists and mediocre managers, promote conformity and enforce procedures and standards that guarantee constant quality - I mean constant LOW quality.
Don't make it free, use all your open-source Rhino components in it and sell it as a "How to use the Rhino Components?" (using etl / security / dsl / etc..)
Sorry, this is blatent self promotion:
Our little eCommerce application, Suteki Shop, has recently been added to the front page of the MVC Framework site, so I guess it qualifies as a sample app of sorts. Of course it's not from MS, but their endorsement will mean that people are going to be looking at it for ideas.
It would be great (but at the same time a bit scary :-) if you could spare the time to take it apart... ducks
http://code.google.com/p/sutekishop/
Mike Hadlow >
A quick look - Whats up with the strange approach to handle viewdata?
code.google.com/.../ShopViewData.cs
Thats a huge WTF imho.
I quite like a lot of Suteki - especially as it was written way pre-release of ASP.NET MVC ... I mentioned it as a good sample app in the first post Oren made on Kobe
My first real exposure to the MS community was via the ASP.NET MVC team. I feel they set a good example and genuinely want to make good code and more than that work at making good code.
Thanks Duckie, that's the sort of feedback I'm after :)
I totally agree, the shared view data sucks.
@Dave
Excellent idea
Can anyone recommend any GOOD sample apps illustrating best practices for ASP.NET MVC?
Best line ever Oren:
The “repositories” in Kobe has so many responsibilities that they are just shy of having a singularity around them
=D
Cheers!
Given Kobe's background, I think its pretty clear why its ended up why it has, back when it started it quickly turned into a learning experience for the creator, he certainly put effort in to find 'experts' in each field (we're you one of them ayende?) to give advice.
What was clear however, and made me lose interest really quick with the series, was that it was relatively amatuer, and more of a sandbox of mashed together learning.
A sample app should be something intermediate (not too advanced, not so simple that its useless), and absolutely needs to be done by someone who has 'mastered' the techniques being used.. certainly not somebody learning them theirself.
Blind leading the blind?
Comment preview