The Challenger of Architecture Astronauts - Two-Tier Service Application Scenario
It continues to amaze me, the length some people will go to in order to add additional complexity. Let us take this article: Two-Tier Service Application Scenario (REST). I will leave aside the arguments about this article gross misrepresentations of what terms like domain modeling, entities and REST. Greg already called the DDD argument, and Colin is working on the problems with the representation of REST.
What I want to talk about is friction. I am looking at the code that is shown in the article and I cringed. Hard. Do you want to tell me that it is recommended that people would write code like this?
I am assuming that I would need to write one of those for each of my “entities” I honestly cannot figure out why. Why create specialized behavior when it would be easier, simpler, cheaper and better to handle this generically?
Is there any sort of value in this code? I don’t think so.
It gets better when you see what you need to do in your Application_Start.
So now, not only do I have to create those handlers by hand, I now need to take care to register each them. I’ll leave aside the bug in the routing code vs. the employee route handler code (‘employee’ is not a route value), to focus on a more important subject. Even if I decided that I want to code my way to insanity, why do I give a single class two responsibilities (creating EmployeeHandler and EmployeesHandler).
I am not even trying to ask why I need the route handler in the first place. It seems like it is there just so there would be another layer in the architecture diagram. It looks like that was a common requirement, because here comes the next step toward the road of useless code:
Except for creating additional work for the developer, I cannot think of a single reason why I would want to write this type of code unless I was paid by the line count.
Let me see how many things I can find here that are going to add friction:
- As written, you are going to need one of those for each of the “entities” that you have. I assume that this is so that all the other per “entity” types wouldn’t feel lonely. On last count, We had:
- Mapping “command” whatever that is, to method calls? So every time that I have to add a new method, I have to touch how many places?
- Why on earth do I need to do explicit error handling? That is why I have exceptions for. Those should do the Right Thing and I should not have to explicitly manage errors unless I know about something specific happening.
Oh, and I saved the best for last. Please take a look at the beast. And unlike the story, there is no beauty.
I truly find it hard to find a place to start.
- Magic numbers all over the place.
- Promote(object data) ?! Are we in the stone age again? I really hoped that by 2009 we would be able to get to grip with the notion of meaningful method parameters! For crying out load, you can use the ASP.Net MVC binder to do the work, you don’t have to do it yourself.
- Null reference exception that are just waiting to happen.
- Unless PositionEnum is not an enum (a WTF all on its own), then the code wouldn’t even compile! Enums are value types, you cannot use ‘as’ with them.
- busErrors ?
- First of all, what bus?
- More importantly, are we back in the good ole days of return codes? I thought we were beyond that already!
- Really bad resource management. C# has try/catch/finally for a reason. If an exception is thrown, you are going to leak the transactions. This is truly sad since the text is very careful to point out that you MUST dispose of those resources before you return.
As I said, I am not going to even approach the actual guidance that is offered there. I think that it is invalid as best and likely to be harmful.
From the code sample shown, I would surmise that no one actually sat down and actually coded any sort of system with this. Even the most basic system would crumble under the sheer weight of architecture piled on top of the poor system.
I am saddened and disappointed to see such a thing being presented as guidance from the P&P.