ASP.NET MVC Samples, Oxite, and Community
Sponsored By
I am writing this sitting on a plane between Joburg and Cape Town, on the way to a User Group meeting to talk about ASP.NET MVC. As I said at the Joburg User Group meeting, ASP.NET MVC is young and we (that is, we the community, not just We, the Microsoft) are still learning about what a "pretty" or aesthetically pleasing MVC application looks like. We have some ASP.NET MVC OSS apps, some Monorail apps, some Rails apps to look to, some Django and Java apps, but we are still finding our way in our spin on this old pattern.
There are still a number of ViewEngines that aren't the default WebFormsViewEngine that are growing in popularity. Folks are familiarizing themselves with the Repository Pattern and other patterns. Folks who had heard of Dependency Injection but hadn't used it are starting to use it. Testability still isn't foremost on many minds.
There are certainly Alpha Geeks, Loud Programmers, or just Talented ones that are impatient with both Microsoft and the community. Why can't they just go from Point A to Point C and skip B?
ASP.NET is mature, and ASP.NET MVC is new. We are all learning, every day. Many folks put themselves out there, in public by sharing their experiences. Quentin Tarentino said:
"He who is most likely to make declarative statements is most likely to be called a fool in retrospect."
There's a lot of Twittering and Blogging going on about Oxite, a new Open Source CMS from a group within Microsoft. It's getting a lot of press, some deserved certainly, but mostly hyperbole. "Microsoft takes dead aim at Wordpress?" Seriously, come on. How come DasBlog or SubText doesn't get that kind of hyperbolic love? ;) "Microsoft predicts DasBlog Global Dominance." (kidding!)
I would encourage you to download the source for Oxite, as I would encourage you to download and read all ASP.NET MVC Open Source applications. Develop your own sense of Code Smell by reading, writing and learning from people you trust. Just because it's called Official ASP.NET MVC Petshop or Contoso MVC Bank or even MVC Storefront doesn't make it gospel.
If you think Oxite or an app that ScottGu created for his blog is the File | New Company project you've been looking for, you'll be disappointed. It doesn't exist yet. Even if it did, you'll likely never be able to Copy/Paste your way to glory.
Oxite is Open Source. If you don't like it, and there are very valid reasons today for concern, I would sincerely encourage you to refactor it and share the results. Follow the project and see what the next release looks like. Just like the ongoing BabySmash saga, let's work as a team to learn what ASP.NET MVC Patterns and Anti-Patterns are. All code has the potential to provide guidance, but you decide if it's a pattern or an anti-pattern. It doesn't matter if Don Box or ScottGu himself wrote it.
I think the team that built it would appreciate it if lots of folks blogged their own "Oxite Code Review" post with improvements and commentary. I want to point you to Rob Conery's most excellent analysis of the situation, and the Oxite code. His review is unblinking, fair, honest, while still kind in tone. Those Hawaiians are just so darned nice.
Javier had an excellent comment on Rob's blog here that reminds me again of BabySmash. I wrote BabySmash wrong, on purpose, with a WinForms-state of mind. I am still working on it today, as it just doesn't smell right.
I think one important thing to note is that Oxite serves as a good example of viewing an MVC implementation from a "WebForms state of mind". This is just my thoughts but I think it would be beneficial to take Oxite and ALTer it a bit to show the flexibility of the MVC framework.
It is a non-trivial think to put oneself, or one's code, out into public. Sometimes it's great, sometimes not so much. But fair, even harsh, criticism can still be constructive and positive. Don't be afraid, Dear Reader, to share your code if you've got it. Some will say it sucks, some will built a corporation around it. Ultimately you have to ask yourself if it was good code, if you learned from it, and if you'd write code like it again.
Rob, ScottGu, Dave Ward and Michael Bach and I are working on an ASP.NET MVC site. It'll be open source, and it'll likely make some percentage of you happy, and some percentage of you sad. Hopefully there will be more of the former, and the latter will share their wisdom and experience and help us make it better. I like being a part of this community for that reason.
The Ruby community's spiritual leader, Matz, is legendarily kind and deferential. As Allan Stevens points out, they say "minswan" meaning "Matz is nice, so we are nice." That definitely jives with the feeling of "ubuntu" and community I'm getting here in Africa.
Be nice, my friends. Write good code, and stay in touch.
I now return me to my regularly scheduled vacation in Africa.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Hosting By
December 17, 2008 15:38
+1 for common sense. The comments in blogsphere about Oxite have been almost outright attacks. I got some great ideas from it, for configuration and Areas (from a blog engine Areas standpoint). And why not use the Provider Model seeing as no standard Dependency Injection library yet exists in .NET 3.5? It looks like a very promising Open Source project.
Andy
Hey Scott, nice breaks from the vacations. Precisely tomorrow I'm giving a talk on SL Architecture and one of my points is how this has been an evolving/incremental and how we have been discovering new patterns, anti-patterns and some bugs also :(
Andy,
You can look at the MVC Contrib project, I heard it made MVC work with different DI libraries.
You can look at the MVC Contrib project, I heard it made MVC work with different DI libraries.
Andy, why cannot Unity be used? That is the official MS DI route, or altenatively Windsor, StructureMap, Ninject, and so on - the provider model is an antiquated pattern.
Scott,
Fair as always, but seriously, this has been put out as an example application, to teach others how todo it properly. And on that criteria it fails mideraly. If this had been a blog engine like DasBlog, SubText, or BlogEngine, no critisiscm would have been evident, as those do not attempt to teach others the "right" way. When you put yourself up as the "right" way, or even a one of the right ways" you are fair game.
Rob was more than tempered in his comments, others have been less so, but with good reason on all fronts. The Oxite application is not just a different style (on which basis ther are many MVC sample projects I dislike), nor is it just one way of dealing with an MVC application, it is a very poor application and fails miserably as a good example to others - worse still it has the MS name behind it.
Honestly, if an employer had paid for this application, they would be looking at significant maintenance issues later on.
Casey
Scott,
Fair as always, but seriously, this has been put out as an example application, to teach others how todo it properly. And on that criteria it fails mideraly. If this had been a blog engine like DasBlog, SubText, or BlogEngine, no critisiscm would have been evident, as those do not attempt to teach others the "right" way. When you put yourself up as the "right" way, or even a one of the right ways" you are fair game.
Rob was more than tempered in his comments, others have been less so, but with good reason on all fronts. The Oxite application is not just a different style (on which basis ther are many MVC sample projects I dislike), nor is it just one way of dealing with an MVC application, it is a very poor application and fails miserably as a good example to others - worse still it has the MS name behind it.
Honestly, if an employer had paid for this application, they would be looking at significant maintenance issues later on.
Casey
Andy's comment is very important because it reflects a very common scenario. Many, many developers that have heard or even played with ASP.NET MVC have not heard or chose to ignore MVCContrib. Why is that? Just because it's not part of the standard .Net installation?
The whole DI thing is well taken care of in MVCContrib. Easy as pie. But it's Open Source, "scawy :("...
After peeking at the code, it's not much different from an average ASP.NET webforms in terms of code quality. Two of the goals of ASP.NET MVC, taken from the original presentations given more than a year ago, are separation of concerns and testability, which are not competently demonstrated in Oxite's code. I think it is a shame that it's being stamped with the "real world" (TM) logo just because it was used for the Mix site. I guess the real world isn't pretty after all ;)
The hope I have is that it evolves to a point that it can really demonstrate the strengths of MVC, not only is the sense of "this can be done with MVC" but "this is why MVC creates a better/more maintainable app".
The whole DI thing is well taken care of in MVCContrib. Easy as pie. But it's Open Source, "scawy :("...
After peeking at the code, it's not much different from an average ASP.NET webforms in terms of code quality. Two of the goals of ASP.NET MVC, taken from the original presentations given more than a year ago, are separation of concerns and testability, which are not competently demonstrated in Oxite's code. I think it is a shame that it's being stamped with the "real world" (TM) logo just because it was used for the Mix site. I guess the real world isn't pretty after all ;)
The hope I have is that it evolves to a point that it can really demonstrate the strengths of MVC, not only is the sense of "this can be done with MVC" but "this is why MVC creates a better/more maintainable app".
I have heard of the major DI frameworks and MVCContrib! I use them. I visit Codeplex every day!
I'm just saying, that the Oxite team's usage of the Provider Model shouldn't just be trashed (I could swear Rob Conery said they used it). They delivered a good grounding for a good new Open Source project. They probably will refactor the AdminController. May it flourish!
Sorry if I sounded as if one should only use libraries baked into .NET or not use the great resources on Codeplex.
PS. whilst everyone argues about DI and Repositories, can someone produce some good articles on validation and ASP.NET MVC. Anyone can persist data. No-one seems to be able to do validation cleanly! And reuse it in MVC and WPF. Hay, even the Oxite site included validation.
I'm just saying, that the Oxite team's usage of the Provider Model shouldn't just be trashed (I could swear Rob Conery said they used it). They delivered a good grounding for a good new Open Source project. They probably will refactor the AdminController. May it flourish!
Sorry if I sounded as if one should only use libraries baked into .NET or not use the great resources on Codeplex.
PS. whilst everyone argues about DI and Repositories, can someone produce some good articles on validation and ASP.NET MVC. Anyone can persist data. No-one seems to be able to do validation cleanly! And reuse it in MVC and WPF. Hay, even the Oxite site included validation.
> we are still learning about what a "pretty" or aesthetically pleasing MVC application looks like
I hope your readers aren't lulled into thinking that the issues with Oxite have to do with mere aesthetics because this notion was pushed onto the cognitive stack early in the article. Even if you personally see the issues as mere aesthetics, it's not necessarily because there are aesthetic issues, but because you may see them that way. A sharp eye, immersed in experiences of driving cost of change and cost of ownership out of code and applications portfolio would see looming liability rather than mere aesthetics. Beyond being ugly, the code is a concrete engineering problem.
> Why can't they just go from Point A to Point C and skip B?
Again, you're skewing perception here. Why is the "become informed/seek input" step something that comes later rather than earlier? There is an easy two-step process that would have remedied many of the issues with Oxite: A) Learn. B) Do.
What we have instead is: A) Presume. B) Err. C) Deny.
> I would sincerely encourage you to refactor it and share the results
Sounds good. Point me to the Microsoft nest egg that you guys tap into for building sample apps and I'm all over it. In the mean time, I have a living to make.
You should be happy that the community of design expertise within the .NET community has given the time that it has. Next step: funding for community leaders to provide the sorely needed guidance that reflects design physics and economics so that they too can write sample apps as part of their living.
> All code has the potential to provide guidance, but you decide if it's a pattern or an anti-pattern
Well, no. That's just irresponsible. Yes, individual developers have to develop a sense for what an anti-pattern is, but many of them are already well known and published. One has merely to adopt a disposition of life-long study and then he can accelerate the honing of his own abilities through the teaching of people who have gone before him.
> Rob, ScottGu, Dave Ward and Michael Bach and I are working on an ASP.NET MVC site.
Because you are putting notoriety behind it, and because notoriety equates to authority in the mainstream, you have a duty to seek input and guidance. You don't get to put ScottGu and ScottHa on the byline of a sample app and not be accountability for the impact it will have. This is a matter of social responsibility.
> The Ruby community's spiritual leader, Matz, is legendarily kind and deferential
The Ruby community is a learning culture. Evoking the Ruby community in the context of Oxite is duplicitous. The cultures and their imperatives are so vastly different as to not be comparable. There is no Microsoft with all of its presumptions and spin in the Ruby community. Oxite wouldn't have happened in the Ruby community. The Ruby community is much more open and transparent and more open than Microsoft culture at large is yet capable of.
I hope your readers aren't lulled into thinking that the issues with Oxite have to do with mere aesthetics because this notion was pushed onto the cognitive stack early in the article. Even if you personally see the issues as mere aesthetics, it's not necessarily because there are aesthetic issues, but because you may see them that way. A sharp eye, immersed in experiences of driving cost of change and cost of ownership out of code and applications portfolio would see looming liability rather than mere aesthetics. Beyond being ugly, the code is a concrete engineering problem.
> Why can't they just go from Point A to Point C and skip B?
Again, you're skewing perception here. Why is the "become informed/seek input" step something that comes later rather than earlier? There is an easy two-step process that would have remedied many of the issues with Oxite: A) Learn. B) Do.
What we have instead is: A) Presume. B) Err. C) Deny.
> I would sincerely encourage you to refactor it and share the results
Sounds good. Point me to the Microsoft nest egg that you guys tap into for building sample apps and I'm all over it. In the mean time, I have a living to make.
You should be happy that the community of design expertise within the .NET community has given the time that it has. Next step: funding for community leaders to provide the sorely needed guidance that reflects design physics and economics so that they too can write sample apps as part of their living.
> All code has the potential to provide guidance, but you decide if it's a pattern or an anti-pattern
Well, no. That's just irresponsible. Yes, individual developers have to develop a sense for what an anti-pattern is, but many of them are already well known and published. One has merely to adopt a disposition of life-long study and then he can accelerate the honing of his own abilities through the teaching of people who have gone before him.
> Rob, ScottGu, Dave Ward and Michael Bach and I are working on an ASP.NET MVC site.
Because you are putting notoriety behind it, and because notoriety equates to authority in the mainstream, you have a duty to seek input and guidance. You don't get to put ScottGu and ScottHa on the byline of a sample app and not be accountability for the impact it will have. This is a matter of social responsibility.
> The Ruby community's spiritual leader, Matz, is legendarily kind and deferential
The Ruby community is a learning culture. Evoking the Ruby community in the context of Oxite is duplicitous. The cultures and their imperatives are so vastly different as to not be comparable. There is no Microsoft with all of its presumptions and spin in the Ruby community. Oxite wouldn't have happened in the Ruby community. The Ruby community is much more open and transparent and more open than Microsoft culture at large is yet capable of.
Thanks for the shout out on my comment on Rob's blog. Interesting enough, I've started a good conversation over at my Oxite blog post.
I totally agree with your comment that just because it has the words "MVC" and some other "MS related" word doesn't make it gospel. Both you and I know that but unfortunately that's not the case for everyone else. I think it's our (the community) duty to help shape that message for the benefit of the technology and the people who use it.
I totally agree with your comment that just because it has the words "MVC" and some other "MS related" word doesn't make it gospel. Both you and I know that but unfortunately that's not the case for everyone else. I think it's our (the community) duty to help shape that message for the benefit of the technology and the people who use it.
@Andy,
Validation with the MVC framework is fairly straightforward. Do the actual validation with some sort of Notification pattern implementation on the Domain entities themselves (where it belongs and where it could be reused in WPF). That takes care of the server side. For the client side, use the jQuery validation stuff. My MSDN article for February has some samples of doing all this and reusing the validation logic.
On the Provider Model, the Provider Model is a very flawed and limited implementation of the Service Locator pattern. Any single one of the mainstream IoC tools (including Unity from MS) will have less impact and provide greater flexibility than the Provider Model. Even if you're one of those shops that can only use the official MS line, you can use Unity.
@Scott,
I'm sorry man, but this post is weak and unhelpful. This is the equivalent of just stuffing your fingers in your ears and screaming "I'm not listening!" over and over again. People take MS code very seriously, and you guys need to take much more care with what you put out. No, it's not fair, but you signed up for it.
"ASP.NET is mature, and ASP.NET MVC is new. We are all learning, every day."
Nuh, uh. That "MVC is this new mysterious thing that no one understands yet" argument doesn't fly. MVC web tools are about a dozen years old in the rest of the development world and you have a tremendous amount of prior art to look at -- if you guys can bring yourselves to pay attention to anything that doesn't originate from Redmond. Besides, many of the problems that I see in Oxite are related to very old, fundamental design and coding principles (magic strings, not favoring composition over inheritance, not paying attention to the Single Responsibility Principle, etc). No, MS employees don't need to be crucified, but the poor coding and design example set by Oxite needs to be addressed and fixed.
Besides, you're not going to learn anything if you refuse to admit that there is problems in that Oxite implementatio.
Validation with the MVC framework is fairly straightforward. Do the actual validation with some sort of Notification pattern implementation on the Domain entities themselves (where it belongs and where it could be reused in WPF). That takes care of the server side. For the client side, use the jQuery validation stuff. My MSDN article for February has some samples of doing all this and reusing the validation logic.
On the Provider Model, the Provider Model is a very flawed and limited implementation of the Service Locator pattern. Any single one of the mainstream IoC tools (including Unity from MS) will have less impact and provide greater flexibility than the Provider Model. Even if you're one of those shops that can only use the official MS line, you can use Unity.
@Scott,
I'm sorry man, but this post is weak and unhelpful. This is the equivalent of just stuffing your fingers in your ears and screaming "I'm not listening!" over and over again. People take MS code very seriously, and you guys need to take much more care with what you put out. No, it's not fair, but you signed up for it.
"ASP.NET is mature, and ASP.NET MVC is new. We are all learning, every day."
Nuh, uh. That "MVC is this new mysterious thing that no one understands yet" argument doesn't fly. MVC web tools are about a dozen years old in the rest of the development world and you have a tremendous amount of prior art to look at -- if you guys can bring yourselves to pay attention to anything that doesn't originate from Redmond. Besides, many of the problems that I see in Oxite are related to very old, fundamental design and coding principles (magic strings, not favoring composition over inheritance, not paying attention to the Single Responsibility Principle, etc). No, MS employees don't need to be crucified, but the poor coding and design example set by Oxite needs to be addressed and fixed.
Besides, you're not going to learn anything if you refuse to admit that there is problems in that Oxite implementatio.
With all due respect, Scott, shut your mouth. The beatings will continue until your attitude improves. You should be thanking sbellware for being a man and spanking you. You need to man up and stop whining like a little child.
The whole community is indebted to the people who threw the first punches. Microsoft constantly ignores the community. Fear and power is the only thing they understand. The only way to get through is to be radical and extreme. Now we have proof of how to get Microsoft's ear. Send paypal donation to everyone who had the COURAGE to flame this. If you have a problem with this, ask yourself when is the last time YOU flamed something from Microsoft? All Microsoft products can use a good flaming. Maybe you do not flame them because you are a COWARD. If you are not part of the solution, shut up and get out of the way and stop hating on the people who have the COURAGE to flame.
I bet Scott starts moderating comments soon. But don't give up. KEEP UP THE PRESSURE. If he deletes the comment, you ARE GETTING THROUGH.
The whole community is indebted to the people who threw the first punches. Microsoft constantly ignores the community. Fear and power is the only thing they understand. The only way to get through is to be radical and extreme. Now we have proof of how to get Microsoft's ear. Send paypal donation to everyone who had the COURAGE to flame this. If you have a problem with this, ask yourself when is the last time YOU flamed something from Microsoft? All Microsoft products can use a good flaming. Maybe you do not flame them because you are a COWARD. If you are not part of the solution, shut up and get out of the way and stop hating on the people who have the COURAGE to flame.
I bet Scott starts moderating comments soon. But don't give up. KEEP UP THE PRESSURE. If he deletes the comment, you ARE GETTING THROUGH.
@Scott:
RE: @Jeremy's post
Whatever MS does, please DO not clamp down on OSS contributions by Microsoft and make it go through some review process as that will stymie everything. The real solution here is for people in MS to start learning core principles and becoming better code designers. MS has an opportunity to be a real leader here and, with Oxite, it has mostly failed to achieve what was possible. It's not a total failure, there's lots of good achievements with Oxite, but there is also lots of bad stuff.
RE: @Jeremy's post
Whatever MS does, please DO not clamp down on OSS contributions by Microsoft and make it go through some review process as that will stymie everything. The real solution here is for people in MS to start learning core principles and becoming better code designers. MS has an opportunity to be a real leader here and, with Oxite, it has mostly failed to achieve what was possible. It's not a total failure, there's lots of good achievements with Oxite, but there is also lots of bad stuff.
Will the MVPs in the house please play nicely! Are you the same people who are trashing Entity Framework?! :)
@Andy: Define "Play nicely". Should MVPs stand by while harm is being done to good software design?
string playNicely = "These over angry comments put off the average community user who is excited about ASP.NET MVC. Sorry for provoking any further impassioned comments. :) ";
I agree with Casey, but what really concerns me is that I agree with Scott Bellware and Jeremy Miller (not something I would normally admit). The META description for the Oxite CodePlex site says the following:
"Oxite is an ASP.NET MVC based blog engine intended to show how to create a standards compliant site using this new framework."
This is the description that shows up when you Google "Oxite", and it pretty clearly says that the Oxite team is trying to hold this up as an example of how to do things "the right way". But, as has already been said, they didn't do it "the right way". Instead of using MVC the way that it was intended to be used (for which there are many examples already available from both inside and outside of Microsoft), they used it as if it were another flavor of WebForms.
It is no surprise that teams inside of Microsoft also have to take some time to adjust to new technologies, just like the rest of us. But unlike BabySmash, where you said from the very beginning of the very first post that it was intended to be a learning exercise, Oxite carries no such disclaimer. If Oxite is intended to be a learning tool, it should say so on the front page in big bold letters. Any entity, whether an individual or a company, which publishes something for public consumption has a responsibility to ensure its quality. But when we are talking about Microsoft, that responsibility moves to a whole new level. To release something like Oxite to the public as a sample for the community to follow, and then after the fact to claim "well we don't know what we're doing yet, just like you" is irresponsible and counter-productive, and hurts Microsoft's reputation in the community.
@Chad
Why shouldn't there be a review process? I'm not talking about red tape, but since when are reviews a bad thing? If the Oxite team had gone to some of the leading MVC users inside and outside of Microsoft, they probably could have gotten a lot of good feedback before going down the path that they did, and made some better choices that could have avoided all of this criticism.
"Oxite is an ASP.NET MVC based blog engine intended to show how to create a standards compliant site using this new framework."
This is the description that shows up when you Google "Oxite", and it pretty clearly says that the Oxite team is trying to hold this up as an example of how to do things "the right way". But, as has already been said, they didn't do it "the right way". Instead of using MVC the way that it was intended to be used (for which there are many examples already available from both inside and outside of Microsoft), they used it as if it were another flavor of WebForms.
It is no surprise that teams inside of Microsoft also have to take some time to adjust to new technologies, just like the rest of us. But unlike BabySmash, where you said from the very beginning of the very first post that it was intended to be a learning exercise, Oxite carries no such disclaimer. If Oxite is intended to be a learning tool, it should say so on the front page in big bold letters. Any entity, whether an individual or a company, which publishes something for public consumption has a responsibility to ensure its quality. But when we are talking about Microsoft, that responsibility moves to a whole new level. To release something like Oxite to the public as a sample for the community to follow, and then after the fact to claim "well we don't know what we're doing yet, just like you" is irresponsible and counter-productive, and hurts Microsoft's reputation in the community.
@Chad
Why shouldn't there be a review process? I'm not talking about red tape, but since when are reviews a bad thing? If the Oxite team had gone to some of the leading MVC users inside and outside of Microsoft, they probably could have gotten a lot of good feedback before going down the path that they did, and made some better choices that could have avoided all of this criticism.
@Andy
If comments about the quality of code puts off average developers from MVC then so be it, better that than they copy Oxite, implement it badly, hve a project failure, and then spout about how MVC is at fault.
MVC is just a pattern, the MVC framework is an excellent framework, and it is just a poor example application that they chose to copy without knowing better that has put them off MVC.
Oxite isn't slightly poor, or just one style of implementation - it is a terribly poor coding excercise. Shockingly poor. This "outcry" has come about because for years develope have been trying to improve standards, to see MS make amajor step forward with ASP.NET MVC ... to then see it tainted by a terrible standard impementation example.
If comments about the quality of code puts off average developers from MVC then so be it, better that than they copy Oxite, implement it badly, hve a project failure, and then spout about how MVC is at fault.
MVC is just a pattern, the MVC framework is an excellent framework, and it is just a poor example application that they chose to copy without knowing better that has put them off MVC.
Oxite isn't slightly poor, or just one style of implementation - it is a terribly poor coding excercise. Shockingly poor. This "outcry" has come about because for years develope have been trying to improve standards, to see MS make amajor step forward with ASP.NET MVC ... to then see it tainted by a terrible standard impementation example.
"Oxite is an ASP.NET MVC based blog engine intended to show how to create a standards compliant site using this new framework."
This is the description that shows up when you Google "Oxite", and it pretty clearly says that the Oxite team is trying to hold this up as an example of how to do things "the right way".
Understand that when they say "Standards compliant" they mean web standards. e.g. the XHTML output is valid and their pages validate according to the W3C standards.
I really like the ability to look at code for these projects. For instance,
private const string antiForgeryTokenSalt = "Oxite gots pages!!!1";
Hurray for anti forgery token salts!
But seriously, thanks for pointing this out Scott. This is one code tree, I will spend some time with. Enjoy the summer in SA!
private const string antiForgeryTokenSalt = "Oxite gots pages!!!1";
Hurray for anti forgery token salts!
But seriously, thanks for pointing this out Scott. This is one code tree, I will spend some time with. Enjoy the summer in SA!
I think someone hacked my hosts file. Instead of going to Scott Hanselman's blog, somehow I ended up on Slashdot . . .
Scott
My problem with Oxite is the second reason for the release.
"To provide a real-world sample written using ASP.NET MVC"
As it is released by a Microsoft team - this "marketing" position statement gives the perception that this is the correct way to do MVC, and as many of the MVC "experts" have commented - it appears to be a bad MVC sample.
My problem with Oxite is the second reason for the release.
"To provide a real-world sample written using ASP.NET MVC"
As it is released by a Microsoft team - this "marketing" position statement gives the perception that this is the correct way to do MVC, and as many of the MVC "experts" have commented - it appears to be a bad MVC sample.
Not much more for me to add to this thread. I find Lars' impassioned comment to be a little Slashdotish, and a little over the top for my taste, but I respect his opinion. I would say however, that there are more constructive ways to dialog on the internet than name-calling. If you don't like something, Lars, change it or make a contribution to it. (BTW, I don't moderate comments)
I don't know the Oxite guys, and I didn't know they were working on anything. Thing is, anyone at Microsoft can put a project together, blog about it, and say "this aims to be a good example of...". Clearly it's not a good example and it shouldn't be advertised as one.
The fact that PhilHa, who owns ASP.NET MVC, didn't know it was going on, kind of makes that point. Any samples from Microsoft that intend to show a Best Practice should be reviewed by Phil, and certainly vetted by the community. David Nelson nailed that point clearly.
I don't know the Oxite guys, and I didn't know they were working on anything. Thing is, anyone at Microsoft can put a project together, blog about it, and say "this aims to be a good example of...". Clearly it's not a good example and it shouldn't be advertised as one.
The fact that PhilHa, who owns ASP.NET MVC, didn't know it was going on, kind of makes that point. Any samples from Microsoft that intend to show a Best Practice should be reviewed by Phil, and certainly vetted by the community. David Nelson nailed that point clearly.
I think it would be valuable to learn a bit from the way p&p does development (although that could be improved too). They have "community advisory boards" typically, where real customers/community experts/mvps get access to frequent deliverables and get to talk on a ccall to ask questions, offer advise, etc. I was part of that process when I used to work for MS p&p, and it generally worked.
The only flaw being that nobody was getting paid for participating, which is one of ScottB's points which I agree: you cannot just expect people to stop making money they need just to give you free advise and time. Some people will do it. Most will just sit on the call silently, as they continue to work on their paying projects.
And I doubt it a bit that *anyone* at Microsoft can put out a sample project and have it mentioned/publicized at a number of important MS properties (visitmix.com, channel9, etc.) and "branded" as guidance.
The fact that Phil, yourself and others deeply involved in MVC had no idea about it, kind of makes the point that this was an isolated project. But if anything else, that's a very good reason to start working towards improving that: there should be no isolated projects that get publicized like this when they don't meet certain criteria. Blame the MIX Online guys, whatever.
It was good that this came out to the light the way it did, I think. If anything, it should make Microsoft much more careful and thoughtful about the consequences of shipping OSS that people will use as guidance/learning tool.
But there's no need to get angry guys! No permanent damage has been made (yet :)).
The only flaw being that nobody was getting paid for participating, which is one of ScottB's points which I agree: you cannot just expect people to stop making money they need just to give you free advise and time. Some people will do it. Most will just sit on the call silently, as they continue to work on their paying projects.
And I doubt it a bit that *anyone* at Microsoft can put out a sample project and have it mentioned/publicized at a number of important MS properties (visitmix.com, channel9, etc.) and "branded" as guidance.
The fact that Phil, yourself and others deeply involved in MVC had no idea about it, kind of makes the point that this was an isolated project. But if anything else, that's a very good reason to start working towards improving that: there should be no isolated projects that get publicized like this when they don't meet certain criteria. Blame the MIX Online guys, whatever.
It was good that this came out to the light the way it did, I think. If anything, it should make Microsoft much more careful and thoughtful about the consequences of shipping OSS that people will use as guidance/learning tool.
But there's no need to get angry guys! No permanent damage has been made (yet :)).
Microsoft needs to be careful when releasing open source software for the purpose of letting developers look at the code. I am sure many MVC newbies/wannabies, by default, will assume Oxite is the proper or encouraged way to develop an MVC app. It would be irresponsible of them to release code that has a lot of issues.
See a critique here: http://codebetter.com/blogs/karlseguin/archive/2008/12/15/oxite-oh-dear-lord-why.aspx
Only knowledgeable MVC developers are able to refactor MVC code so your advice applies to those people only and not developers who do not know MC and they are the majority of asp.net developers.
Code from "nice people" does not make it good code!
See a critique here: http://codebetter.com/blogs/karlseguin/archive/2008/12/15/oxite-oh-dear-lord-why.aspx
Only knowledgeable MVC developers are able to refactor MVC code so your advice applies to those people only and not developers who do not know MC and they are the majority of asp.net developers.
Code from "nice people" does not make it good code!
Lars,
I appreciate your support for the effort to bring more accountability and responsibility to Microsoft and to the Microsoft sphere of influence and influencers. It's a long fight, a valuable fight, and there's a long way to go yet before the community truly starts to believe in it's own voice. I appreciate your courage for adding your voice.
I hope you can appreciate that I would denounce your comments here because you have coupled me to them.
And I hope you can appreciate my own capacity for nuance that simultaneously allows me to sympathize with you and the unabated aggravation that is at once fueled by Microsoft and it's employees, and spun by Microsoft and its employees into something more innocent and uneventful than it is in reality.
I agree wholeheartedly that now is the time to keep up the good fight, and to keep the pressure on at every opportunity until Microsoft makes real efforts of its own to tear down it's own hubristic barriers between its own isolated product development efforts and the knowledge that is evolving at a much faster pace in the community of practice and expertise outside of those barriers.
I appreciate your support for the effort to bring more accountability and responsibility to Microsoft and to the Microsoft sphere of influence and influencers. It's a long fight, a valuable fight, and there's a long way to go yet before the community truly starts to believe in it's own voice. I appreciate your courage for adding your voice.
I hope you can appreciate that I would denounce your comments here because you have coupled me to them.
And I hope you can appreciate my own capacity for nuance that simultaneously allows me to sympathize with you and the unabated aggravation that is at once fueled by Microsoft and it's employees, and spun by Microsoft and its employees into something more innocent and uneventful than it is in reality.
I agree wholeheartedly that now is the time to keep up the good fight, and to keep the pressure on at every opportunity until Microsoft makes real efforts of its own to tear down it's own hubristic barriers between its own isolated product development efforts and the knowledge that is evolving at a much faster pace in the community of practice and expertise outside of those barriers.
Develop your own sense of Code Smell by reading, writing and learning from people you trust.
That's kind of a contradiction. I did exactly what you say here, I downloaded the code to learn from it, and I trust Microsoft to deliver really good stuff. Especially when it's aimed at developers to show them how it should (could?) be done. Then I see Oxite, and it smells. So I am developing a 'sense of smell', so far so good.
Then uncertainty strikes. This is from Microsoft right? These people are doing this for years, right? THIS is how it's done? Are they sure? It seems smelly. Am I sure? I just don't know anymore...
Another example is Rob Conery's series. It's excellent, but then you read the comments, and again the uncertainty strikes. Wait, is this good or bad? Should I take his advice, or his?
Also, I don't think LINQ to SQL should ever be used in a DDD example, because you can never model your domain with it. Ask Rob Conery, he had to map all the LINQ to SQL classes to his model classes, an exercise in futility. Also, database independency goes straight out of the window when you use LINQ to SQL, because Microsoft has not made the effort to open up the framework so others can write providers (always with the lock-in you people, seriously uncool).
Oh, and DI in ASP.NET MVC? Autofac for the win, seriously... No code example is complete without DI, how else to isolate your tests?
So to conclude, the recent efforts and examples have made this developer more confused. I have learned from it so far, but that's because I go on intuition: I think I know which parts of MVC Storefront are good, and which are not. But I'm never sure...
Lastly, some tips for the app you are working on:
1. Don't use the Membership providers, implement IIdentity and IPrincipal.
2. Don't use repositories in the controller, assume a reuasable business logic layer is needed.
3. Create at least two repository implementations, one using NHibernate for example.
4. Show leadership by representing a 'new' pattern for sending expressions down to the data layer, and sending iqueryables up to the layer(s) above.
5. Use DI and explain why the dependencies are configured where they are.
6. Write sensible unit tests. Realise the wisdom of xUnit.net (maybe even use that instead of the Microsoft NIH test framework).
7. Use Moq, it rocks and everyone should use it (opinionated I know, but what are you going to do, wait for a Microsoft mocking/stubbing framework or not do it all, neither is a good solution).
8. Use SQLite, just to show that there is something else besides SQL Server 2005 Express and user instance=true. Hey, that effectively rules out LINQ to SQL, bonus! Now you see why it's not cool to use LINQ to SQL for examples, there are actually other decent databases out there.
9. Use database migrations. What, Microsoft doesn't have a framework for that yet? Too bad, Oxite included a project that could only be opened with some $ 1000+ Visual Studio framework, nice 'community' example you 'insensitive clods' (just kidding, but still...) I would suggest Migrator.net
10. Don't make it a blog, blogs are the Northwind of ASP.NET MVC examples.
Looking forward to the example and guidance, good luck with the project!
Valid quality concerns aside, this also seems to be a branding problem.
Scott appeals for Oxite to be given the courtesy received by BabySmash which is clearly sub-branded as "Scott's WPF community learning project" underneath the Microsoft brand umbrella. But Oxite doesn't get that courtesy.
Other open-source "Microsoft" projects are clearly sub-branded as coming from folks like patterns & practices, the ASP.NET team, individual bloggers, and so on. People have a fairly good idea how they should pidgeon-hole code that originates from these various sources. But not Oxite.
Oxite was loosely branded as "from the guys behind Channel9 and visitmix." What does that mean?? I know perfectly well what Channel9 is, but unfortunately my sound bite impressions of their brand image (videos, community) doesn't translate to help me quickly place Oxite in perspective. Adding "open source projects" to Channel9 dilutes their brand. It also doesn't help that they try to dodge their identity and affiliation in their overview: "We aren't a sample-building team (more on what we are in a bit)."
I would argue that they should have started with a clear description of who they are and then moved on to discuss what they're releasing. Perhaps people would have been kinder and less over-the-top as a result.
Scott appeals for Oxite to be given the courtesy received by BabySmash which is clearly sub-branded as "Scott's WPF community learning project" underneath the Microsoft brand umbrella. But Oxite doesn't get that courtesy.
Other open-source "Microsoft" projects are clearly sub-branded as coming from folks like patterns & practices, the ASP.NET team, individual bloggers, and so on. People have a fairly good idea how they should pidgeon-hole code that originates from these various sources. But not Oxite.
Oxite was loosely branded as "from the guys behind Channel9 and visitmix." What does that mean?? I know perfectly well what Channel9 is, but unfortunately my sound bite impressions of their brand image (videos, community) doesn't translate to help me quickly place Oxite in perspective. Adding "open source projects" to Channel9 dilutes their brand. It also doesn't help that they try to dodge their identity and affiliation in their overview: "We aren't a sample-building team (more on what we are in a bit)."
I would argue that they should have started with a clear description of who they are and then moved on to discuss what they're releasing. Perhaps people would have been kinder and less over-the-top as a result.
Does MVC still render controls the same way it did in WebForms, with circa-1994 table code for stuff like wizards and textboxes, and really rough table code that can't be styled for stuff that must be tables, like datagrids, etc.?
If so, why wouldn't Microsoft go all the way and change the control rendering? What good is a div around a table with poorly-thought-out class names?
I'm sorry if this doesn't touch Oxite so much, but at the x/html level, the whole premise is still broken if all you can do to write to web standards in MVC is wrap a standards-based layout framework around the same old, same old table code. It's been what, 4 revs of VStudio? What's it going to take for Microsoft to get some religion in any group other than the browser teams?
We all have to work together. Make it easier!
If so, why wouldn't Microsoft go all the way and change the control rendering? What good is a div around a table with poorly-thought-out class names?
I'm sorry if this doesn't touch Oxite so much, but at the x/html level, the whole premise is still broken if all you can do to write to web standards in MVC is wrap a standards-based layout framework around the same old, same old table code. It's been what, 4 revs of VStudio? What's it going to take for Microsoft to get some religion in any group other than the browser teams?
We all have to work together. Make it easier!
Amen to fixing the legacy rendering for web controls... 3.5 is trying to address this (somewhat) with the listview but there is still MILES TO GO... for the love of God what does my <asp:Label> control render as a SPAN tag... why? why? Why is everything wrapped in a table - regardless if it should be a table (gridview) or not (repeater)? Its really no wonder our design and skinning teams hate us using .Net and plead for PHP/java... at least they know a label is a label.. and not an inline element... arrghhh!
Please Scott - help us champion xhtml!
<off soapbox - and sorry to redirect comments but the last post got me fired up! ;) >
kind regards,
Kevin
Please Scott - help us champion xhtml!
<off soapbox - and sorry to redirect comments but the last post got me fired up! ;) >
kind regards,
Kevin
The ASP.NET label control renders as a LABEL element if you specify the AssociatedControlID attribute, i.e., the for attribute. Of course, I want to throttle the "genius" who thought "AssociatedControlID" was an acceptable substitute for "for."
Not that I think AssociatedControlID is a great name, but "for" is a reserved word in many programming languages. It would be really cumbersome to use a property named "For" on the server code. Same issue for CssClass instead of Class.
In ASP.NET's defense, if you hate the rendered HTML so much, you can use old school (ASP classic style) ASPX files (i.e. avoid webcontrols) or use Control Adapters to render that label or anything else they way you want.
In ASP.NET's defense, if you hate the rendered HTML so much, you can use old school (ASP classic style) ASPX files (i.e. avoid webcontrols) or use Control Adapters to render that label or anything else they way you want.
@sergio
ASP.NET is touted as a "web" language - if it wants to be seen as such - it needs to render valid xhtml without manipulation or adaptation. W3c and xhtml compliance is not a bad thing - and making websites that have valid rendering is better for everyone (developers, design, and - more importantly users). If MS truly wants high end website work done with .NET then it needs to make sure that the rendering engine deficiencies are addressed. Further, .NET is touted as helping to rapidly build solutions without heavy customization and low level plumbing (web controls, memory mgmt, etc.) - yet - to get valid rendering that is exactly what you have to do - removing that gained efficiency.
Take a look sometime at an asp.net website with a Jaws reader and tell me how fun it is to try and decipher what is going on - heavy, blatant, and unnecessary nesting of tables injected at runtime really trip up screen readers and make it difficult to split design and development (although MVC should help with this).
Lastly - if ASP.NET is going to include and adopt jQuery as a represented js framework (which is a GREAT thing IMO) they will have to clean up the rendering as using css and DOM selectors via hierarchy relationships doesnt work when inline and block level elements are injected. Try doing jQuery("table > tr") with a gridview and you will find that the selector returns null because a gridview injects an extra table for no reason at runtime to wrap itself.... this is just one example - there are many many others.
I agree with your post that there are ways around it... I just dont think that the extra steps should be taken for something to be done the right way.
Best,
ASP.NET is touted as a "web" language - if it wants to be seen as such - it needs to render valid xhtml without manipulation or adaptation. W3c and xhtml compliance is not a bad thing - and making websites that have valid rendering is better for everyone (developers, design, and - more importantly users). If MS truly wants high end website work done with .NET then it needs to make sure that the rendering engine deficiencies are addressed. Further, .NET is touted as helping to rapidly build solutions without heavy customization and low level plumbing (web controls, memory mgmt, etc.) - yet - to get valid rendering that is exactly what you have to do - removing that gained efficiency.
Take a look sometime at an asp.net website with a Jaws reader and tell me how fun it is to try and decipher what is going on - heavy, blatant, and unnecessary nesting of tables injected at runtime really trip up screen readers and make it difficult to split design and development (although MVC should help with this).
Lastly - if ASP.NET is going to include and adopt jQuery as a represented js framework (which is a GREAT thing IMO) they will have to clean up the rendering as using css and DOM selectors via hierarchy relationships doesnt work when inline and block level elements are injected. Try doing jQuery("table > tr") with a gridview and you will find that the selector returns null because a gridview injects an extra table for no reason at runtime to wrap itself.... this is just one example - there are many many others.
I agree with your post that there are ways around it... I just dont think that the extra steps should be taken for something to be done the right way.
Best,
Track back from http://webdevvote.com/AspNet/ASP_NET_MVC_Samples_Oxite_and_Community
@Sergio:
Control adapters are incomplete, and introduce more problems than they solve with the behaviors and events. Right now, MS doesn't even control a complete, working set of Control Adapters, as they released that project to the development community, and I can tell you from firsthand that that's still in development.
Also, interviews with members of the Visual Studio development team that I've seen on such sites as Channel 9 indicate that they largely don't give a crap about the code that renders from controls, and think that people are just hating on MS (or worse, play the "you think you're BETTER at dev than me?" card) when they bring up this very valid concern. I fervently wish that would change.
Kevin is absolutely right. Jaws is the most poignant example, but even more common is the hour of extra work per page instance that it takes GUI (skinners) to just MEET design spec. You don't want to be around people who've had to spend Christmas Day at the shop splicing repeaters and other code together to even hand-wave at accessibility standards. Especially if your page or control is what kept them there.
I WANT to use Microsoft tools. But I don't have an argument to counter to people who want to switch to Rails for this very reason.
Control adapters are incomplete, and introduce more problems than they solve with the behaviors and events. Right now, MS doesn't even control a complete, working set of Control Adapters, as they released that project to the development community, and I can tell you from firsthand that that's still in development.
Also, interviews with members of the Visual Studio development team that I've seen on such sites as Channel 9 indicate that they largely don't give a crap about the code that renders from controls, and think that people are just hating on MS (or worse, play the "you think you're BETTER at dev than me?" card) when they bring up this very valid concern. I fervently wish that would change.
Kevin is absolutely right. Jaws is the most poignant example, but even more common is the hour of extra work per page instance that it takes GUI (skinners) to just MEET design spec. You don't want to be around people who've had to spend Christmas Day at the shop splicing repeaters and other code together to even hand-wave at accessibility standards. Especially if your page or control is what kept them there.
I WANT to use Microsoft tools. But I don't have an argument to counter to people who want to switch to Rails for this very reason.
I think a better example (i'm biased) of using MVC to create a content management system (or blog engine) can be seen in the latest release of BlogSvc.net. I think someone should do an architecture comparison between Oxite and BlogSvc. BlogSvc has come a long way since it was last featured here on the weekly source code 32.
I define success in application if: it solves the business problem it was designed to solve.
Oxite clearly worked for Mix and other sites it has been used for. They decided to share the code. Not as a best practice for MVC but rather how they used MVC in the real world.
My problem with this is that people look to Microsoft to make up their minds about design practices, this is a process that should be arrived at through your own process of learning, and testing.
Don't beat Microsoft guys back into obscurity, but rather encourage the idea of sharing. I think this was the spirit of the post and I whole heartedly agree with it. It is a lot easier to criticize than to do.
Oxite clearly worked for Mix and other sites it has been used for. They decided to share the code. Not as a best practice for MVC but rather how they used MVC in the real world.
My problem with this is that people look to Microsoft to make up their minds about design practices, this is a process that should be arrived at through your own process of learning, and testing.
Don't beat Microsoft guys back into obscurity, but rather encourage the idea of sharing. I think this was the spirit of the post and I whole heartedly agree with it. It is a lot easier to criticize than to do.
Wow, a lot of cat fighters on this post. I agree with the last post and others contradicting. Those who follow standards like religion are fuming because oxite does NOT adhere to that religion. If you are waiting for MS to tell you how to do your job(which i believe most of us do), then you should blame yourself not MS. That doesn't mean that those who are MVC religious cannot point out their views. Views are views and they are yours. Look to Jeff Atwood's use of MVC in stackoverflow.com and he will tell you that he doesn't claim it to be whatever MVC compliant means but rather, his(and his team) aim was to use the tools he had to produce the best solution for the job. And he did, the site was so good that people were asking him if it was written in ruby-on-rails. So yes, might not be the best practice but it turned out(with he experience and smartness) to be a very good solution for the problem he and his friends were trying to solve. That said, at least Jeff admitted that his code was probably not perfect and best practice.
Comments are closed.