The Code Spaghetti generation is back

14 Comments

• Thank God I'm not the only one who's thinking this right now. I noticed it a lot with ASP.NET books, too.
  
  
  
  I think that the authors of most of these books are not as smart as they think they are. Some of the books are amazing, others are textbook examples of what not to do.
  

• I think of it this way: The framework doesn't tie you to a specific level of programming. You can perform the task using well-designed layers and conform to best practices and such. But also, the framework provides this level of 'spaghetti' programming because there are programmers out there who are more familiar with this kind of code.
  

• SqlDataSource should die!
  

• Amen! The Microsoft Quickstarts are full of examples like this. It's *really* shameful. Code-behind isn't a great solution but it's a hell of a lot better than this crap.
  

• Thanks for speaking out on this issue.
  
  
  
  It is quite shameful that one keeps seeing this everywhere.
  
  
  
  Reading this books is simply boring, and I guess writing them
  
  must be even more boring, how do they stand it, or do they not
  
  know better.
  

• Well Charles, I have to disagree with you. Over the last few years, many developers learned how to avoid the spagetti code, now it means that for newbies, forget everything we said before, it's good to produce junk code! At least I would like to see book writers a bit more responsible and not just swallow what Microsoft say like if it was the word of god.
  
  I have no problem to see this code but it should be followed by some warning note.
  
  I stuck to the code behind even if it's not perfect because I can't imagine my SQL procedures screwed by some mistakes in my HTML code! And as an 'old' coder I don't see any advantages to produce this monstruosity. And the example I show here is very basic, add to that all the CSS, the static HTML code and eventually some Javascript DHTML code and try to swallow that :-) Good luck if you have to change something!
  

• "SqlDataSource should die!"
  
  
  
  SqlDataSource in itself seems legit to me; it is the implementation and usage that requires questioning. As I mentioned previously, I think it's perfectly acceptable to use the sample given as these are *quick*starts, not "long drawn out lenghty exercies that require a computer science degree and masters in software engineering".
  
  
  
  One interesting use of SqlDataSource would be to pair it up with a Factory pattern so that each page doesn't declaratively create a SqlDataSource, but has access to some sort of Factory object which builds the requisite SqlDataSource based on some inputs and returns it to the page for databinding.
  
  
  
  Admittedly, it's a shortcut to building a true object oriented design, but a true object oriented design isn't always necessary or called for; just like take out is a shortcut to a homecooked meal, but a four course homecooked meal isn't always necessary.
  

• Different features are useful for different scenarios and different classes of developers. One of the things that we've tried to-do with ASP.NET is layer the architecture so that developers can use different capabilities in a flexible way, and choose what is "right" for them.
  
  
  
  For example, some developers want more flexibility than .aspx pages give them, and so write to the low-level IHttpHandler APIs which provides ultimate flexibility (but requires a lot more discipline and effort to use). That doesn't mean one approach is "bad" or "good" -- the ultimate value/usefulness of it depends on the scenario and developer.
  
  
  
  In terms of datasources, there is a base datasource class that all ASP.NET datasource controls derive from (including ObjectDataSource, SiteMapDataSource, SqlDataSource and XmlDataSource). You can also build your own datasource control that derives directly from the base class for ultimate flexibility.
  
  
  
  For the most maintainable and clean code, we recommend using the ObjectDataSource and encapsulating your data access code within either a DAL (data access layer) class ideally wrapped by a business layer class (and that has no concept of UI). This provides a nice, very clean, OO abstraction -- and still saves a lot of time and effort over V1.1.
  
  
  
  For simpler reporting scenarios, or cases where developers don't understand OO concepts like classes, the SQLDataSource control can also be used. This has the downside which is that the data access code can't be re-used across pages, classes or projects. The data code also isn't factored cleanly. But for cases where you are looking to build something quick and dirty, or where a developer doesn't understand OO concepts, it can help get things done. Note that the UI code is the same regardless of whether a developer is using a SqlDataSource or ObjectDataSource -- so it is possible to move the data code out from a Sqldatasource implementation into a BLL/DAL implementation using ObjectDatasource without having to change existing UI code.
  
  
  
  In terms of samples -- the ASP.NET QuickStarts show lots of different scenarios, and they include samples of both the ObjectDataSource and SQLDataSource. All of the ASP.NET Starter Kits, which are more full fledged samples, use the ObjectDataSource control.
  
  
  
  Hope this helps,
  
  
  
  Scott
  

• What *really* peeves me about this new model is that with the 1.1 bits it was 100% possible to write an entire web application with NO markup. This is no longer the case. In 2.0 if you want to 2-way databind, get ready to deal with markup. It simply isn't possible (if anyone finds a way, please kick me a mail)
  

• In answer to Paul's comment:
  
  
  
  Anything stored in a .aspx file can also be represented in a code-behind file as procedural code. If you want an ObjectDatasource definition defined in your code-behind file, just add an event handler for the page/control's initialize or init event and manually create the control, set properties, and add it into the page tree.
  
  
  
  The ObjectDatasource needed to be implemented as a control vs. a standalone component, because the only way to add support for 2 way data-binding is to have a class that intimately understands the control model (which is why this is implemented as a control).
  
  
  
  Hope this helps,
  
  
  
  Scott
  
  
  
  P.S. It is worth mentioning that 2-way databinding doesn't exist in V1.1, so this is a new thing -- not something easily done before.
  

• While the addition of the declartive type controls are I'm sure a welcome addition for the amatuer developer, it would be nice if the advanced features were availible to developers that don't use the declartive style (i.e. GridView).
  

• Microsoft has always pushed new products by showing "new features" that consist almost exclusively of things that you should never actually do in real life. Richard Tallent (I think?) made a great name for this smoke-and-mirrors demo practice: "Gee-WYSIWYG".
  
  
  
  The demos are great for demo purposes ("ooo... ahhh... look, I didn't write a single line of code!") but I have always found it sad and slightly disturbing that MS sells VS.NET using features that should never be used by the people that buy the product (with the exception of protypes, quick proof-of-concepts, and other apps you will later completely scrap and write from scratch with code).
  
  
  
  

• To echo Joseph Cooney, this isn't spaghetti code. Spaghetti code was ASP 3.0, where you HAD to mix actual code (VBScript, whatever) with markup. I believe what the complaint is here is essentially two-tier data access, no?
  
  
  
  Jason Tucker, what features of the GridView are not available to developers who don't use declarative style?
  
  
  
  Paul D. Murphy, when you say "no markup" for 1.1, do you mean a) no HTML (aka markup), b) no declarative controls (e.g. <asp:button>, aka markup), or c) no declarative data access? For the life of me I cannot see the advantage of (a) for 99% of Web developers, and I still kinda wonder about (b).
  

• I think M$ has given this for RAD development / small demo's which you need to prepare / mockup's / poc's to be developed in a short term. The same time, they've given, ObjectDataSource also, which can be used. The application needs to be designed in such a way that we use ODS, not SQL DataSouce controls.
  
  
  
  JiniShans