+972 52-548-6969
Application review: Northwind Starter Kit
I continue to try to find a sample application for Northwind to use as my contrasting example for an article that I am writing, and I found the Northwind Starter Kit project. Even the project summary page gave me a few twitches, here is a small piece with the twitch inducing stuff bolded:
The application has been designed using common patterns, such as the ones defined within the "classic" "Designs Patterns" by Erich Gamma et al. and "Pattern of Enterprise Application Architecture", by Martin Fowler; though not required, these lectures are strongly recommended.
Guys! This is Northwind, the likelihood that you’ll need design patterns to build this application is nil to none! That just screens complexity overload.
Domain logic is implemented by means of a Domain Model, onto a layer of services adds application logic. The model is persisted by a DAL designed around the principles of the "Repository" patterns, which has been implemented in a LINQ-friendly way.
Northwind is a CRUD app, at its core, all of those things are adding complexity, and they aren’t really adding much at all. In fact, they are going to create just noise, and make working with things that much harder.
And then I opened the project, and I got this:
I mean, really? Seriously?! 22(!) projects to do a sample application using Northwind?
This is the point where I gave up on this as something that could be useful, but here are a few other gems as well:
I really like how the Update method does what it is meant to do, right?
Note that in either implementation, we are looking at totally and drastically different behavior.
Let us look at the interface, too:
The design is straight out of Patterns of Enterprise Application Architecture, and it is totally the wrong design to be using if you are using a modern OR/M.
Seriously, this is Northwind we are talking about, why make things so freaking complex?!
Comments
simply, because you totally missed the scope of the project. that is, at the end, to explain architectural design patterns with a sample application. Northwind db is there only because this is the most known in the MS universe, it could be any other db. the project home page statement is very clear about that...
sorry the doubled comment, please ayende feel free to delete the spammed content
Design patterns for the sake of having design patterns. Yuk.
@Roberto: If Ayende misses the scope of this project, as you say he does, what do you think inexperienced architects will do? I'll tell you: they will cargo cult this bloated, cumbersome, over-engineered architecture into their own applications, even when it's not warranted, thinking it's a "best practice" even though they have no idea whatsoever what's "best" about it.
Certainly there is no reason whatsoever why you should have 22 projects in an application of this scope. You should have the minimum number of projects in your solution that you can get away with, otherwise you will end up with dependency management nightmares and compilation times measured in geologic eras.
Kind of sad. Talk about scaring developers away from new technology. The best sample project created by Microsoft is probably Nerd Dinner. Not that Nerd Dinner is perfect, but it is a real site that can be used and had a purpose.
Honorable mention to Rob Conery's MvcStoreFront project.
Man this is crap code.
Ayende I am really surprised that you evaluate a solution based on its size or an architecture based on the number of layers. I grew up on NSK as it was my first layered application, almost 5 years ago and I personally believe that the effort Ugidotnet has put into this project during the years is simply amazing. The architecture reflect the most common architectural design patterns and represents almost the concepts expressed by Fowler and Evans. NSK is not a project to teach you how to work with Northwind and it is not a project designed exclusively for Nhb. It is designed to show how a layered application should be architected in .NET and there is also a book wrote around this project. I believe that your quick evaluation of this community project does not really represents what NSK is trying to accomplish.
"...intended to be used as a blueprint when designing and implementing a .NET layered application architecture..." I think this clearly says, what this example is all about. I don't understand, how one could read it as "...this is how you should design und implement a Northwind application..." Sometimes, i really miss the point of reviews like this...
1: I'm not involved at all in the project, nor I have any interest in it. 2: I do not think it's a fair review, since you are public person with a lot of given credit stating that something is bad could simply produce a disaster for that something even if it is not bad at all. Could simply produce comments like the tobi one ("Man this is crap code.") where I'm pretty sure that tobi has never seen the whole codebase. 3: Is like saying that the RavenDB project is crappy becuse in the solution there are 17 projects (that is not far away from 22), but we all know that to run RavenDB you do not need all the 17 projects, everyone can open the solution and understand at the first look that in the solution there are tests and different implementation for different technologies (Munin, Esent, Full fx client, Silverlight Client and so on). 4: Fish added one more good point. 5: Writing something like this "The design is straight out of Patterns of Enterprise Application Architecture, and it is totally the wrong design to be using if you are using a modern OR/M." is useless unless you tell us why.
Just my 2 cents. .m
+1 for Roberto and Fish.
I appreciate what you're trying to do here, but this analysis is completely out of context with the point of the project.
http://dl.dropbox.com/u/678683/greatest-shitstorm-of-our-time.jpg
The story is simple...Ayende just doesn't like this code because he didn't write it
Some day I hope you might look back on the tone of some of these of posts and perhaps feel a bit of guilt for the school yard bulley you turn into every so often. You've had an impressive career, especially considering how relatively young you are. It's disappointing to see this kind of immaturity when constructive criticism would earn you so much more respect. I will continue to follow your blog and I enjoy learning from you. Please consider learning something from this.
@Roberto I don't think that explaining(as well as using) design patterns just for the sake of the design patterns is useful. Actually it's horrible. A design pattern is useful when there's a need of it, if it's used when there's no need of it it's simple overhead. So a better way of learning and teaching a design pattern is when you put it in a context which is appropriate for it. Much more value for the "student" that way.
@Fish A "blueprint" of an application should fit the business needs of the application. There's no point of using the same architecture or patterns for different projects with different needs. That follows the thought about - a design pattern should be used when it's needed.
That project would have had much bigger 'value' of it were using real world scenarios. The way it is now - it has very little to none value for learning design patterns. I think it will even confuse and mislead most of the people who will look up to it for learning as they probably won't know when to use the patterns that are implemented and use them as they are used in the project.
to me "OnlineStore" (that is one of the projects and one of the top folders in the src) sounds like a real domain...and also stuff like IMarketingServices, ICatalogServices and if you take a look (as I did) at the HomeController you can immediatly see that is something real, that simply work and that simply solves that problem its own name states to solve: it's an online store.
.m
For sure Ayende hit the point that an example with 22 projects is enrmous "per se" whatever is the scope.
@felice if you download a nhibernate sample applications that contains also the entire source code of nhibernate, with all unit tests and so on, you can easily have a 22-projects solution, I think. Maybe not, but the point is that NSK is not a sample app, so what are we talking about? this is NOT a "sample application for Northwind"
What's the problem with technology demo applications? All of them are crap or you are concentrating only on the bad ones?
Design patterns, domain models, multiple layers, services, application logic, DALs, repositories... These are all concepts developers will need to understand if they are going to successfully develop even slightly complex applications.
One of the best ways to help developers understand these concepts is with sample applications. The initial sample applications developers should study should be simple stripped down ones, just to get them used to the concepts. It would not be productive to dazzle them with a full production quality mega application. We need all the concepts, but not too much functionality.
Therefore, some of these 'beginners' sample applications may not accurately reflect real world applications. Yes, they may utilise more concepts and paradigms than is needed for the functionality, but that is the nature of these applications - they're not supposed to be practical solutions!
As experienced developers, it becomes very difficult to place ourselves in the position of someone starting out, but everyone has to start somewhere.
+1 for Ayende
@Paul, I see your point. Nevertheless, Ayende's post carries a valuable message: I've seen too many software projects, especially in the "enterprise" world, horribly doomed by "architects" over-designing systems.
In my opinion, learning to avoid those bad practices is at least as important as learning design patterns.
@Mauro, of course over-designing is a bad thing, and if an application like this was a real world project and put in to production then it would be a bad solution. But it is not, it is an application to demonstrate how to use design patterns. This seems to have been missed.
However, I must add that I think the Domain Model pattern does not add significant overhead to a project, and is always worth considering, even for very simple projects _because you never know how complicated it will become in the future_.
+1 for Mauro I also would state that architect's main goal should be to remove useless complexity and useless code as much as possible
The domain model looks pretty anemic to me. The repository abstraction does not add much value either.
The problem with such examples is they do not show WHY you would want to use those patterns.
To all the critics above, I agree with you that it's not fair to judge the usage of patterns and the raw number of projects in this application, since the purpose if NSK is to demonstrate those.
BUT, there's no excuse for Select N+1, no excuse for wrong implementations of the Repository pattern, methods just return null or the unvalueable seperation between projects.
It's generally ok to have a repository patter, but then it should be implemented right, especially in demonstration app. It's also ok to have 22 projects, but the seperation should make sense and be valuable for the codebase.
I'd have to spend more time looking at it, but I actually didn't think it was that bad as a starting point. It appears to be a project created by a group of developers who work at a consulting firm as a place to learn new technology ideas. This isn't some guidance out of Microsoft to which I'd hold a higher standard.
In fact this project appears to track along with the same lessons I encountered in the last year on a project I worked on, even seems to have hit some of the same stumbling blocks. So I can empathize.
Yes there are a number of things that I would do differently and that comes from trying something and learning from it.
Oren's tone isn't justified.
I a gree with Daniel Lang
<there's no excuse for Select N+1, no excuse for wrong implementations of the Repository pattern, methods just return null or the unvalueable seperation between projects.
It's generally ok to have a repository patter, but then it should be implemented right, especially in demonstration app. It's also ok to have 22 projects, but the seperation should make sense and be valuable for the codebase.>
NSK was developed to show the concepts expressed in this book. http://www.amazon.com/Microsoft%C2%AE-NET-Architecting-Applications-Pro-Developer/dp/073562609X Ayende, I am surprise that you would be so slating in your assessment of a project written by another respected author in the dot Net community. It's easy to forget that we as software developers are all somewhere on a learning curve. The book and the NSK project are a few years old now, but in my opinion together they do a good job in describing some of the concepts and ideas needed to put together a maintainable layered enterprise architecture.
When I read posts like this, I start to wonder if the author produces just perfect code all the time.
@Daniel Lang:
Just my curiosity: where is the Select N+1 and why the repository implementation is wrong?
.m
Pardon my ignorance, but I can't think of a single online store that needs something as complicated as this?
Wow. How many times are you guys gonna let Ayende troll you? What suckers.
This review is a travesty, a sham, and a mockery...it's a travishamockery!
@Ayende have you considered continuing with your Macto series as a Best Practices example? Count me in if you need volunteers; I see that as a more constructive way to illustrate the proper use of best practices. Thanks!
I would like to know what's wrong in details too, especially about repository implementation, with ORM best practice (repository injection into domain model vs not), layered ddd architecture [dont look at 22 projects, the base ddd solution has 3 projects + UI (Domain, Repository implementation, application services) plus some infrastructure like InversionOfControl/Deploy. Off course you can put the first tree things in the same project and a sub folder, patterns are what matter :D
Raciel, Yes, I want to make this go forward. Will probably do something about that in a few weeks.
Ah, I see some of the Spaniards are back that were so angry about Ayende's DDDD Sample Project reviews from mid 2011.
The reality is, over complicating a simple problem to prove a point is never a good idea, especially in the .NET world where "cut and paste from MSDN" could be listed as a skill on most developer's resumes. Stuff like this only ends badly.
I don't understand why you are bashing on this code project. Of course the project is overkill for the Northwind database but this is a starting point. For my projects, i have analysed a few open source code and i have taken the ideas that i liked from them: SharpArchitecture, NSK to name a few.
For those of you that say that NSK is crap, that the repository implementation is wrong, why don't you fork the code and propose a solution for that? It's very easy to bash on things but i didnt see anyone explaining the Why and the How to solve the problem or how to do it better.
I'm not a guru programmer so i can't argue with you guys on all the architecture stuff and good programming. This is why i'm really desapointed by this thread since that i didn't learn anything by reading you except that you are making fun on this guy very easily.
If you think that you are so good at coding frameworks, why can't we see any code and learn from you?
alex
Totally agree with Alexandre. Lets see some real examples of what's wrong, with some why's and how's to solve them. you make me really scared to release code into the wild, why take the risk of getting shat on so you can all congratulate yourselves on being so clever. you don't see nearly so much bashing outside of the ms world
Totally agree with Alexandre. Lets see some real examples of what's wrong, with some why's and how's to solve them. you make me really scared to release code into the wild, why take the risk of getting shat on so you can all congratulate yourselves on being so clever. you don't see nearly so much bashing outside of the ms world
btw, your comments also suck. hope you get a good bashing over that too
I don't really understand the reason behind these posts. In my opinion NSK is a sample and meant to show how to implement various design patterns using the MS stack. Creating samples is not an easy task. If You go for a complex problem (where the design patterns make more sense) the complexity might make the sample too difficult to understand. However if You go with simple stuff many patterns feel unnatural since those will look as an overkill for such simple problems. I do not want to say that NSK is perfect since no software is, but at least it gives people some ideas and they can decide on their own if these ideas match their requirements or not. If You have improvement ideas You could have used the time taken to write this post to contribute them instead.
Another application same as all other apllications these days. Maybe you could look at https://github.com/Lokad/lokad-cqrs/tree/lean. This is something from guy that blogs here http://bliki.abdullin.com/ and here http://abdullin.com/about-me. He looks very clever to me but I don't know much about event sourcing.
Yeah, it's very sad that people spend time writing these useless samples. It's possible to show proper usage of architecture patterns with Online Store project. First of all, prices of goods do change, so each item is represented by multiple rows in database, at least it's (id, date_effective) or up to three columns with dates. So you hide this price-changing logic in some wrapper to make basic searching easier. There goes repository etc.
Slamming repositories and units of work on top of ORM which already implements these patterns is stupid and shouldn't be teached. A person who can recite GoF book is not a good architect, the one who knows when to use patterns to make code better is.
NSK is not an easy project. I start to “read” it some years ago and I found really difficult to understand it, but I never think that it was a problem of the project (or of its developers). My feeling was that I was not ready for it. Some years after I have the possibility (and the luck) to study better the underling architectures and I start to understand how to “use it”. At the moment this is not a sample app that you can reuse “ready, steady, go” on you projects. I use it to search suggestion about design or implementation, knowing that I have to write my own code to use it in my solution. It, also, try to investigate new topics (like CQRS) when there is no so much implementation reference project around. I think this is another good thing. Even if I do not think that you can measure a solution using the number of project, the large number of project is due to the fact that this solution tries to embrace the most common frameworks/tools. A real and complete implementation of a MES project (layered and with test project) made using lot of pattern inspired by this project count “only” 11 projects (obviously we have chosen only one ORM and one presentation design pattern).
Comment preview