Plip's Weblog

It is a recognition of the audience that Microsoft is targetting.
I don't think that your 2 statements are absolutes.
I think you can accurately say:
When building an enterprise application, inline SQL and coupling your UI to your database is bad.
However, I think you can also accurately say: When building a quick "solve this problem" application for yourself or a small number of users, inline SQL and coupling is ok. In fact with the new features being introduced, this is probably the "preferred" method, since it drastically reduces the learning curve and overall development time.

Of course, the trick is making sure your enterprise app developing colleagues know better than to use the RAD tools for production applications. Easier said than done, once they are available.

And I'm just adding - I'm never moving my projects to Asp.Net 2.0, they're going to be rwwritten in Java (Struts probably). Magic folders, especially the one called Data where the framework disabless access to it did it for me. Because all my data logic (rendering XML files off of a database) is in a /data folder and I'm not going to move it every time Microsoft decides to make life easier to morons.

Josh,

I have to say, that I don't even resort to the "quick and dirty" methods even when I am protyping my code, I know that my code will need to be maintained... and if not by me, by some other poor unfortinate person.

Phil -
Do you think it is possible to over-engineer an application? If not, than I understand your post. If all applications need to be built with the same robustness, maintainability, portability, etc, then I agree that all sample code should demonstrate those "absolute" practices.

However, if you agree that some applications do not need the same level of engineering, that "best" practices do not necessarily apply to all applications, then requiring all sample code to adhere to them does not seem necessary.

Consider a single-page web application that allows you to view and edit a table in a database. You want to include a new field in the display. Is it really easier to have to change your presentation layer, business layer, and database layer? As opposed to changing a couple queries in the page? Remember, this is not an enterprise application.

Josh,

I work with building blocks, I have standard templates for my projects, each solution consists of the following projects are a bare minimum.

Provider Specific Data Access
DAL
Error Reporting
Business Objects

From here I add either a Web Site or windows application, then I code against them...

For quick dirty stuff I still do this, why? Because in my experience "quick and dirty" turns in to something the sales director has just gone out and sold to our clients...

Future proofing my code by building it properly in the first place saves me time and energy later on.

This is just how I work :-)

Plip,

What about the XmlDataSource and the DataSetDataSource objects?

Wally

Ok, I guess you don't believe in over-engineering ;)

Just kidding. It sounds like in your environment (sales directors selling your incomplete code) you have to build everything as a robust enterprise app. While I agree that is probably a more common environment than we would all like, I don't think it is universal.

oh dude you have no idea. here in the world of the FINANCIAL INDUSTRY, HTML UI = APPLICATION. yeah, you heard me right.

having a ui means having an app. so for each app, write a new freaking ui.

don't use objects.
don't use C# like its strongly-typed, but rather, write FREAKING ASP PAGES IN C#.

yeah, i'm miffed. you could say so.

I totally agree with Phil. In my experience, code samples and many of the inbuilt controls that you are implicitly encouraged to use in .Net are fundamentally bad practice. This is very worrying when you consider that this is how many people learn to write business apps. Luckily, I graduated from the MS school many years ago and moved to Java, where things are 'done right' :)

And the argument about over-engineering is somewhat flawed - how many applications have you written which end up being used for 5x their intended lifespan and become a critical part of the organisation, even though they started off as a 'little side thing'? Applications have a tendency to grow well beyond their initial intended use, and this is disastrous from a maintenance point of view - and some poor soul has to mop up after you someday. Doing it properly does not have to be more time consuming, especially when you have good, reusable frameworks such as Struts to draw on. Starting off on the right foot saves more time than it costs, every time.

I think that the new controls are an asset to the framework.

True, they're *not* what you would want to use building an enterprise application, but 98% of the websites out there today are *not* enterprise applications.

These types of controls, like the drag-and-drop-and-it's-all-you'll-ever-need gridview are what bring rich, dynamic, fully custom web applications to the little guy...To the family that wants to let their relatives know what's going on in their lives, and to the hobby shop that wants to display some of their unique inventory items online to draw in potential new customers. These controls make this sort of application cheaper, and easier to build then ever. These sorts of applications don't *need* the design, and the performance, and the expense of an OO, XP-architected, robust, scalable structure.

The argument that they allow enterprise developers to slack is also bogus. It's the job of the enterprise architects, and the program managers to make sure that their applications are designed and built correctly, with the appropriate considerations taken, and coding standards and practices followed. It shouldn't be the job of the framework itself to force proper technique. If, as a manager, your developers arev writing bad code, that's your fault, not the language's they're using. If offering developers RAD shortcuts is the issue, let's just all go back to C/C++, and forget the .Net thing altogether.

Taking away tools doesn't do anybody any favors. Good managers, architects, and developers are still going to write solid enterpise applications using best practices, and bad managers with lazy developers are still going to write bad code...So let's not punish the small application developers for the faults of others.

A bit more: http://blogs.aspadvice.com/xsherry/archive/2004/07/11/1347.aspx

I completely agree with Plip that always designing from an "enterprise" perspective, even for the little intranet app only a few people will use, is the way to go. Not only does it prepare your "little" projects for the "big time" when the time comes, but it shows you're a step above the rest, and a professional.

I disagree with those who think it's safe to promote amateur coding techniques to newbies. This simply promotes and extends amateur coding.

I know it's PC nowadays to cater to "everyone" and give everyone the same chance, but some things need to be done to standards, and sometimes things need to be left to professionals.

Where is your pride in our profession? Do you want small businessman Joe coding his own shopping cart from MSDN examples, or hiring you to do it the right way?

Talk about outsourcing.

Replied to Fran here:

http://blogs.aspadvice.com/xsherry/archive/2004/07/11/1347.aspx

EVERY application is enterprise level! If you think it is not, give it 5 years and it will be...and if you did not build it to be from the start, some guy like me will be mopping up after you at 5x your rate. Why 5x your rate? Because who wants to work on a piece of garbage application that's going to require 12 hour days to fix?

Some...no...a lot of people (companies) think that any application is going to become obsolete sooner rather than later and will have to be re-done anyways - so why not do it as quick and cheap as possible? Here's a quick flash of reality to you: WRONG! If the application is built right the first time (scalable), it will grow and adapt as the company does.

Show me a drag and drop method of programming that offers scalability like object oriented programming. Can't? That's right - there isn't one.

I for one am quite glad I found this post. I was beginning to think that I was missing something. I thought maybe this horrible SqlDataSource control was offering something I wasn't understanding. Glad to see it's not just me.