No more declarative programming please

Writing ASP.NET 2.0 applications is harder than before. Yes you read well, harder. If you are a newbie or an amateur of declarative programming, you're safe. I am not an expert, I place myself in the middle ground, but yes damn it it's hard.

I am struggling today with the real deal, a new project where as a serious programmer you have to do all the plumbing from behind the curtain.

Yes I admit I hate declarative programming. It's the lazy way of doing things properly; drag few controls, drag one datasource on your page, type few SQL commands, and hop your site is ready.

No sorry but for me that's not enough. I like to learn, I like to know what's going on in my project from A to Z. OK maybe not to Z, I let the framework doing the last goo by itself.

Take the Gridview control. It's great stuff, but if you want to learn properly all the possibilities you have on offer, exception of googling, can you use one of the dozen existing books on ASP.NET 2.0?

Not really! Unless I didn't buy the right book, they are falling in the declarative programming trap.

In ASP.NET 1.x, it was so easy to declare a datakey. It took me a while to understand the new way. Not that I think I am stupid but in all the books I have, they declare the datakey field on the Gridview tag.

Yes now it's there, but some reason they change the method name. Well of course this is only one little view on the issue.

You can see dozens of examples all built in one page, mixing the client side script, the user controls, the ASP.NET controls, and the sql datasource, and worst for most of them the code behind is written in the ASP.NET page itself!

Where are the layers separation? I don't want to sound like a war veteran, but I find more easy to go through my code if everything is done as a two or three layers project.

So my message to Microsoft, is to get more balanced in the next version of Visual Studio and give more on the code behind, and to the technical writers please less declarative programming (or in in proper english "spaghetti code").

 

16 Comments

  • I vote the exact opposite.

    Less code behind and more in the aspx page, thank you.

    I hate digging around through multiple files to find out where things are buried.




  • Are you serious? Or are you talking about some other ASP.NET that didn't come with MS .NET?

    I handed a very important e-com site from a friend to a PHP freelancer that I knew pretty well. He's supposed to be a pretty good one at it too. He used Drupal and after almost an year, the client(friend) begged me to take it over and get it finished as the PHPer was making a mess of it and hadn't fixed it. Guess, how long it took me to do the whole thing in ASP.NET. Less than 3 weeks of part time work.

    Well, I think the right advice to you is ditch the books. Do google, MSDN and all that stuff. Learn it the hard way. When you do, you'll understand the mindset of the ASP.NET team and everything else will just be so obvious to you.

    If you don't have the time, apply for vacation...

  • I don't know what you have been looking at, but is easily doable to seperate all the layers from each other without much code (Or even none) an doing all the aspx design from the VS Designer :)

    Just use stuff like ObjectDataSources instead of SqlDataSources, so that you can put the sql statements in the correct layer and you can work with business classes etc..

    Visual Studio was not made for the hard core coder or even for the intermediate coder, which you call yourself, it was made for EVERYBODY. So also for my nephew who doesn't really care about layers and who thinks NHibernate is the new gamestation from Nintendo...

    Every new thing has changes, your car also. Or would you still like to ride horses? Just because in 1400 we did, doesn't makes it the best way to do it. If renaming a method solves problems or makes things more clear / easier, then they are totally right to do it (Unless they promise backwards compatibility, but look at JAVA what kind of horror that brought along)

  • - Dee I understand your point of view but digging is also a good thing. I find that some stuff are faster to do from the code behind than using the designer. Also I question the readibility and maintenance of a project done entirely in one layer.

    - Sameera, yes surely I need some vacations but that's not the subject here ;-) Serious I am! in ASP.Net 1.x I am very confortable at coding a database connection, in ASP.NET 2.0 it's more job if you don't want to use the 'lazy' way.

    - JV of course I know you can do layers but sorry not from the designer! Check your source code to see where all the things are done. An ObjectDatasource embedded by the VS Designer stay on the ASPX page! I hate to see my connection strings and query in a presentation layer, this is not really serious.
    Of course I am not against progress. I am a geek! However before .NET we were introduced to the ASP world with spaghetti code, I don't understand the logic behind the decision to come back to that time.
    And yes VS is addressed to everybody, thanks for that. But you should have a better balance between those who are beginners and the other crowd.

  • Well, you can choose the way you like.

    But I agree that the ASP.NET 2.0 books brings you to the declarative direction.
    With the experience I have learned how to read a technology-focused book, it's very different that in school when we learned the lesson and applied that in the exam.
    Now you must read about the fantastic datasource controls, be pragmatic and take a look to those controls with Reflector.
    After being horrorized by the amount of stuff GridView has, you decide not to use it in the critical parts of your work. But for internal code like administer some DB table GridView with SQLDataSource or ObjectDataSource if you have the DAL done is okay.

  • An ObjectDataSource has only a link to a class + method + (parameters if needed) which it needs to call. So your connectionstrings and queries aren't at the presentation layer at all. They can easily be put away in a DAL. Eg: ASPX -> ObjectDataSource -> BL (Seperate dll) -> DAL (Seperate dll). Works like a charm and exactly what you want.

  • Sorry to disagree, but I think declarative programming is great because it's so much faster and opens the platform to a wider number of developers.

    I agree that having everything in one page violates the "rules" about separating tiers. However, for small to medium size applications, I don't think it matters that much and the deployment is so much easier.

    If you need to understand how to do everything in code, use the ASP.NET wizards to create a working site and then decompile the generated assemblies with Reflector. You'll see just how "real" programmers would build it if there were enough days in the year.

    Ken

  • HOnestly, I cannot stand Generic DataSours at all. I design all my datasources, connection objects, Data/Logic/Business layers all by hand.

    I love using 3rd party controls, but I am very fickle with performance, and I like to know exactly how things work.

    An ASPX page/ASPX.CS page should never, ever, ever know what SQL is, or anything to do with SQL. It might know what a Datatbale is... maybe... but I mostly use ILists for everything.

    HOwever that's just me, and my team. I'd rather spend 1 day doing something by hand that might take someone 10 minutes by dragging something onto a page. But at the end, mine will execute faster, and it will be more extendable...

    This comes from a guy who's solution currently has 23 code projects and 9 WAP.

  • "An ObjectDatasource embedded by the VS Designer stay on the ASPX page! I hate to see my connection strings and query in a presentation layer, this is not really serious."

    It sounds like you're still confusing ObjectDataSource with SqlDataSource. To give you an idea of how far off you are, you don't even need a database to bind data with an ObjectDataSource so there's no "connection string" or "query" required.

  • JV partially agree with you, yes Objectdatasource is the one I think is the best method to use, but whatever you do you still have a tag on your aspx page for that.
    It's really easy to break the code when the class name is embedded with HTML. It's just annoying.
    Of course if you swear only with the Design mode why not.
    But I still think it's not 'clean'. But the worst for me are all the books written with SQLdatasource and SQL queries inside the .aspx page. This is for me a no go.

  • Also guys one more point: I LOVE ASP.NET ;-)
    I just wish that Microsoft think not only about beginners but also about programmers.
    By the way can I create programmatically an ObjectDatasource (without any tags in the .aspx page??)

  • Does anyone really use design mode? You could remove it from the editor as far as I'm concerned.

  • I know a few that use design mode... they're the fresh ones out of University... where the only web class in 4 years they took was with FrontPage.

    I think the only use for design mode is to quickly get make event listeners :P

    Double clicking on a button is way quicker than writing the event listeners by hand.... i think that's one of the only benifits of design mode...

  • What you've described (drag/drop, etc) is not declarative programming. Doing that stuff does create declarative style code (i.e. it adds markup to the ascx/aspx page which defines the objects), but that's the extent of the declarativeness of it.

  • Most don't organize their code consistently. Some is in code beside, some in code behind and some is in compiled dll's, or some irrational combination.

    Everybody follows a different combination of declarative approach on how to create a web page.

    Many try to impress with a "windows" style development when all they need is a simple low tech web site.

    Some use "projects", some use "websites", some use "web applications" .

    It's a hodge-podge gobledygook.

    Some mix languages. ugh!





  • I agree with the author, as a Microsoft based programmer for many years I've learnt to take every new latest and greatest feature with a grain of salt and go with what I think best conforms to modular design, segregation of layers and maintainability (and also efficiency).

    Declarative programming IMHO is 2 steps back for VS developers, just so Microsoft can market "wow, look, anyone can use visual studio .net and develop a website in 10 minutes". Sorry guys, when a system needs to run fast, perform well and must be maintainable, then I will go with my gut feeling and do it the way I think is best, not the way microsoft think I should do it. Saves me a headache in the long term, assuming I take pride in my work and don't just want to slap things together in 10 minutes.

    People seem to forget (assuming they've been programming MS for more than a couple of years), that most often when a new feature comes out they are bombarded with microsoft telling them they should use it and then it's demoted in the next release, causing huge pain and anguish and wondering why it's no longer mentioned and dies a slow death.

    A simple example is ViewState, have a look at the anguish that caused some developers, wondering why their pages are so huge and bloated and bringing servers to their knees and clients transferring the same data back and forth to the server. But, if you take the time to know exactly how viewstate works, use it sparingly and use smarter programming on your pages, you can get around most of it's pitfalls, while still keeping the useful features.

    I am guessing the same thing will happen with declarative programming, many people will use it and many will find out that it doesn't scale and is a maintenance nightmare for large complex projects.

    Again, I have to say that this is a personal thing and really depends on your target market, size of project, and corporate methodologies (if any).


Comments have been disabled for this content.