+972 52-548-6969
ReviewMicrosoft N Layer App Sample, Part II–getting lost in the architecture
Continuing my review of http://microsoftnlayerapp.codeplex.com/, an Official Guidance (shows up at: http://msdn.microsoft.com/es-es/architecture/en) which people are expected to read and follow.
So the first thing that I saw when I opened the solution was this:
Yes, I know that this is a sample application, and still, this bit scares me. I have never really used the modeling support inside VS, so I took a look there, to see what is going on.
Take a look at one of those:
Do you see the problem here?
As usual with those sort of questions, it is an issue of what is not here. There is not a single mention of the actual application. To be frank, at this point, all I know is that it is a sample application, but I don’t know what the sample is about.
This is pretty scary, because I am pretty sure that if this is the case at that level, we are going to see much the same as we go deeper. I decided that it might behoove me to figure out what this application is about, so I checked the database project, and found:
Um… so it looks like it is about a bank, but also about books, and orders and software. I don’t really see how they connect right now, but we will see, I hope.
Comments
software is hard! right?
@Ayende...
Two cents..
1º Whether you do not agree with you, you keep forgetting (intentionally sure) of project scope:
"It is an Educational example, not a real world system, it shows educational scenarios, easy to understand useful from a patterns implementation point of view, but not necessarily as a whole business application. The architecture is decoupled and relatively complex so it would allow to grow your system."
2º You should be showing an old version of the solution because this is not what I've downloaded yesterday ... ummmmmmmmm!!
I hope that you doesn't judge all software seeing only a layer diagram and a bunch of sql files... I think that this post is another "meaningless" assumption and not very much significative. I'm completely sure that you haven't read the book (http://download.microsoft.com/download/9/F/A/9FA4753A-FC8A-40DE-9EFA-CCAFB4C835FC/DDD_NLayered_NET40_Architecture_Guide_Microsoft_16_05_13.zip). Please, read it first!!
Do you know that there is a whole book explaining the architecture? I recommend you first read the book and review the code.
Today I reviewed the architecture codeplex page and there is an alpha version. I think it might be a good option to send your proposals.
Maybe is not the best architecture but I think it's a very good reference architecture on which you can look for your developments.
Well people need to understand that we chose architecture based on requirements and not the other way around!
This is classic example of where SE is moving... It is moving away from what it was designed for.
You don't choose DDD just because you want it! You choose it if it's warranted.
I agree with Ayende, there is no need for such complicated mess if application is a "simple sample". I haven't looked around this project, but If I would have, I would started from looking at Test cases if SRS etc was not available.
Code talks, book walks!
Code is the single point of truth. Get the code wrong and no book will be able to fix it.
@Sergey Shishkin,
You've downloaded the latest version, v2, and have seen the project?
http://microsoftnlayerapp.codeplex.com
Jhon R.Dt
@Sergey
This is your personal point of view I hope...
Read the manual that comes with it before spreading some FUD
This solutions comes with excellent documentation. We can't say that of all projects ... For once a project with quality documentation is released and it isn't even read before making ones mind.
If you want to figure out what this application does why not start with "1.4 Domain" ? Or the database if you prefer but that says less.
As the documentation states (and other commenters repeated) this massive categorization of the solution is only justified when working on big projects. Cesar went so far to make this guidance applicable when working on big projects. You have a point that the application that comes along with it is too small to demonstrate the usefulness of (indeed a massive) division into solution folder/projects.
But whats the point groking a big domain if the point of the project is too grok DDD applied to .NET? Use a bit of your imagination and think about the DDD concept of bounded contexts.
Just take a step back and leave out if something isn't justified.
Ayende,
I always enjoy your blogs, but I now find myself skipping the blog and navigating directly to the comments.
Controversy. I love it!
btw: I believe Kash was one of the authors.
"Do you know that there is a whole book explaining the architecture?"
Oh sweet, its hard for me to get behind solutions that don't come with a book to explain what's going on.
I was just wondering when reading these posts... what happended to the Macto sample? :)
Why is the fact that there is an entire book dedicated to this architecture considered a good thing? Why oh why does everything that comes out of Microsoft have to be so ridiculously complicated?
+1 for macto! I've been waiting for that for ages!! :-)
Would be more than happy to pay towards the cost of it, but I guess Ayende's rates have gone up a bit in the last few years!! :-)
@Eric
You are wrong. I'm one of the readers, and I use some of the concepts and ideas behind the guide and the code, not all. For me it has been a very helpful stuff in my daily work. Attitudes like this do not help anyone, only cause confusion. This produces me angry...
"This produces me angry" ---> "This makes me angry"
('produce' as a verb means creating something tangible...use "make" for emotions etc)
@Kash,
With all due respect, how does "attitudes like this" not help anyone? Oren was sent an email asking him to review the architecture, he is simply doing as requested.
When a movie critic gives a movie a bad review, is it the critic's fault that the movie wasn't good?
First people bash Microsoft for doing drag-and-drop demos and now that they put something together that implements patterns people are complaining. What do you want Microsoft to write your app for you? The first thing to remember is that this is guidance. You would be a fool to take this whole example and implement it line by line. You need to design YOUR architecture to fit your needs. This app is just showing you what you could do with patterns and the .Net Framework. If you like the repository pattern great here is one way to implement it. If you want to use a Unit of Work, here is an implementation that seems to work.
This example taken as a whole as the gospel is the wrong way to look at it. The book that everyone seems to want to ignore was written first and the example was made to support it. The book does a good job of explaining why choices were made and in some cases some alternate courses of action. I agreed with different sections and other sections I think are completely wrong. In the end I learned a few tricks that I can implement in my architectures (when they are called for).
@Steve
" is it the critic's fault that the movie wasn't good"
Better to say that the critic didn't think the movie was good, other people can disagree with his opinion, it doesn't make the software/movie any more or less 'good'.
@Steve
I think that the problem is he is writing this review in parts. People are taking his initial impressions as a whole through evaluation of the project (code and book). It is interesting to get an insight into how he evaluates a project but I will wait for his final assessment before I would critique his critique.
@Steve
Such criticisms are not constructive, at least until now. I will wait for the next posts to see if there are some compelling reasons to confirm what promise in their titles ...
JhonRed, 1) I am well aware of the project scope, I am disagreeing with the ability to do what they want within that scope. 2) I am posting about the code that was available at the time that I wrote, which you can read at the bottom of the post.
@Robert Byrne
Good point, my analogy should have been "is it the critic's fault he didn't like the movie".
People are free to disagree with any critic's opinion, don't tell the critic that having his opinion is wrong or unhelpful.
Secondly, Oren is known to be incredibly tough when he reviews code, yet they asked him to review the code. It's not like he went looking for a fight, they came to him.
I would not dare to judge the architecture with this little information. But I agree with Steve that having to read a book in order to understand an architecture does not make it a "good" one. What is the point of a sample application if it is not self-explanatory :P especially if it is the goal to explain concepts.
BTW: this is also a nice talk about architectures in general:
http://www.infoq.com/presentations/Simplicity-Architect
Have fun
Fer, I scanned through the book, yes. Nothing that was new or unfamiliar to me, same stuff as the original. And no, it doesn't make it better.
I can not find the sense, that sense has to do a review of something that has changed?
Jhon R.D
Tom, You can show off this architecture in a small project. It _doesn't work_. Worse, because it is a small application, they layered on a lot of stuff that is unneeded and harmful. They could get away with it because the application is less than northwind.
Erik, I never got the time to do it.
Dave, Maybe I would like to get quality guidance, you know, stuff that I can say I am happy to implement in my applications or see people implement?
@Kash,
I'm not sure I get why his comments should be considered "not constructive". They're not flattering by any stretch, but he doesn't approve of the application. So is anything not praising the application "not constructive"?
I agree quality guidance is important. I too think the example is too small to fit the architecture that they are promoting. In your opinion are there situations where this architecture would not be considered over kill? The projects that I work on would not warrant this structure as a whole but there are parts of it that are useful. I just think that it is nice to see a Microsoft example that doesn’t go from a data grid on a page directly to a database.
@Steve
Because he does not provide any valid argument to say that something is wrong. I only see subjective and partial judgments.
To all. The document is very good and it summarizes the majority of good patterns and practices of enterprise architecture. But look how thos patterns are implemented before bushing Ayende. Look how IoC container is called directly instead of infrastructure calling it. Look how DTO's are manually mapped to entities instead of infrastructure doing this.
Off topic. I hate BlackBerry on-screen keyboard.
Dave, That is really a complex answer, because it comes in two parts. * The architecture that they say they are advocating. * The architecture that they are actually advocating.
DDD has its place in big, complex applications where the major thing is complex business logic. What they did is a complex technological mess. I don't think the later should be used.
And I like going directly to the DB, there is rarely a good reason to want to wrap those things up.
Do you like going directly to the DB from an aspx page? What is the reasoning? How is the performance for long running SQL Querys? Do you uses services?
Dave, No, not that. But I see all too often people setting up 7 layers of indirection to do a single select. You can see my series of posts about the Whiteboard project for more details, here is one: http://ayende.com/blog/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer
Dave A good way to see how I currently write applications is this sample app (also this blog): http://github.com/ayende/RaccoonBlog/
Ok. That is what I mean when I say going directly against the database. I agree many layer of indirection are not necessary. I did see that post. For the most part I agree but there are times when a repository pattern makes the code a little cleaner. But you should not use repositories for the sake of using a pattern. You should apply the pattern when it makes sense.
That is one of the things I don't like about this N-Layer app is that they hide the data access behind repositories and specifications. They also like to implement patterns that are already implemented in the .Net Framework, for instance they recreate the Unit of Work when the ObjectContext is already a unit of work. A little over kill!
Cool. I will check out your app.
I hope I don't end up stirring things up more here, but I think there is bit of a cultural divide here. In US/EU people professionally disagree by prefacing with "yes, on the other hand perhaps..", "I see what you mean, but..." etc etc. to keep everyone's feathers smoothed. In Japan and Thailand, my experience has been that people would rarely even disagree with any statement, just nod approvingly. Other cultures go somewhat in the other direction, and expect you to be forthright/frank without verbal prophylactics.
Peter, In Israel, we say: "You are wrong, and that is why"
I prey to the gods that my career will never hit such a project. I am working on 50k of self-written lines of code and although this is not huge this is not small either. I still manage to get by with two C# projects and queries inside of my controllers. Have never found anything wrong with that approach yet.
Other than https://github.com/ayende/RaccoonBlog/
Can you recommend any other sample applications that shows good architecture for non trivial applications?
@Ayende I'll let you say that!
True story: my colleague in the pharmaceutical industry, in preparation for a business meeting in Japan emailed the Japanese team (in some big conglomerate like Hitachi) an excel spreadsheet with data to discuss in the upcoming meeting. He flew to Tokyo a month later and was put up in a hotel on their dime. In the meeting they basically hemmed and hawed and tried to make him realize without them actually saying it that they didn't want to proceed with his product. He pushed them until they mumbled some misgivings about certain lack of data in the spreadsheet. He then showed them that the data was there on a different "sheet", accessible by clicking on it's tab at the bottom. Their mouths dropped open and everything was cleared up ... all he had to do was come back to Japan for another meeting in a few months when they had looked at the data...
Joe, Look at Alexandria and Effectus for other examples
I can't say I agree with the general comments on the code sample (http://bit.ly/mSTS8V). I will be interested to see if feelings change if/when people read the book.
I think you're missing the point of this guidance. The title clearly indicates that this is a reference implementation of THE "DDD architecture", which I believe has already been defined extensively in the blue-book. You can't just say you want to remove various components that you think you can do without, or to trim down all those layers, because then you will be missing some essential components involved in the formal blue-book DDD architecture. You see, the microsoft team do not invent their own new architecture and encourage people to follow it. They just simply take THE already-well-known blue-book architecture and show how you'd implement it using microsoft stack. It's not a guidance of how you build ANY KIND of applications. If anyone feels that this architecture is too complex for their requirement, it just simply means that DDD doesn't fit their projects. But when you do want to embrace DDD, this guidance shows you how, and i think it serves its purpose well. I see how some ms technologies can be fit to the picture in ways that I did not see before, and I think it's a good thing. Your review should really focus on specific implementation flaws that can be improve, rather than bashing the whole architecture itself, because following the DDD blue-book is the whole point of this guidance, and I can't see how any criticism on that front would be any useful for the authors
Just to clarify when I said you can't remove some components defined in DDD. Of course you can. What I meant by that is you can't remove those things from a DDD reference-guide, because if would be like missing chapters
Hendry, I have written multiple DDD apps. This isn't how you do it.
DDD doesn't have to be done that way, but this guidanance uses the standard DDD architecture formally laid out by the blue-book. You got a point about its sheer complexity of it, but that seems to be a critisim that should be directed to the DDD architecture, not this particular implementation guidance
A good example is the specification pattern, which I'm well aware you're not a big fan of, and indeed only few apps need it. But any DDD guidance won't be complete without covering specification pattern. At least it may give .net developers a pretty good idea of one way you can implement the pattern on microsoft stack should you ever need it
Hendry, That is actually not the case. DDD was written about a decade ago, things change. You don't need specifications if you have Linq, you don't need to build repositories if you have an OR/M, etc. Those things were moved into the infrastructure, no longer required.
Hi!
What do you guys think about the Layered Architecture Sample for .NET? (http://layersample.codeplex.com)
Regards, Serena
I also wish you had taken a different approach to this and admitted you dislike ddd.
Why don't write your own book or series about this.?? Personally, I applaud microsoft for still believing in ddd!! I love ddd and oop princples should always be a part of .net and yes I love prism and unity dependency injection . I really hope that you really encourage and challenge developers to develop greater enterprise skills like oop techniques! That is what really make software enginerring fun Ayende, you could have 100 software engineers and everyone would have their opinion on how good software should be written. I am willing to listen however I may respectfully disagree with you, that's what makes it fun to debate!! Have a great Day!!
Comment preview