Pontification – Page 2

ASP.Net MVC: Quick Overview of Controller Structure

Wow, that’s a mouthful far as titles go, but couldn’t think of a better way to say it. Now what I’m about to go through is the “system” I have found that works pretty well when it comes to structuring controllers knowing that there will be asynchronous operations. Why is that a big deal? Well where you put certain methods can depend on which controller actually owns the action.

When I started using MVC, I had some issues on figuring out how to build controllers so that they made sense from a structural point of view. I slightly touched on it but I wanted to show where I progressed to in the vain hope that I can help prevent stumbling on your part.

One thing to be noted is the asynchronous part. I’ve become a firm believer that MVC is pointless without asynchronous operations. Why? Simply put, you can use them or you can come up with some annoying post and redirect for any create, update, or delete operations. If you’re going to do that, you might as well just be institutionalized because you are one masochistic mother f—er. For everyone else in the happy world, go with something like jQuery that makes it real easy to perform said operations.

With the last paragraph in mind, the part I had trouble with the most was figuring out where the actions go. You see, when I started using MVC, I grouped stuff in an ultra simple manor. Say I have a site for handling pictures. Well there would be a view controller that would have anything to do with viewing images and an admin controller that took care of the uploading, changing, deleting, ecting. As you can imagine, this was not what you might call ideal.

Once I got a feeling for MVC and how it worked, I started having things a little more separated but still didn’t feel right. I had actions for viewing a list of images on the image controller no matter if public or admin side which wasn’t really ideal to me since it kind of blurred what was public and what was restricted from a conceptual point of view.

It wasn’t until I started thinking in terms of unit testing that it started to make more sense. If I were creating controllers as if they were classes instead of pages like with WebForms, maybe it would work out better. Seems real profound right? Well it was at the time since I still had WebForms state of mind. All of a sudden, it made way more sense on how the controllers should be set up. In an odd way, the controllers almost became almost business layer like. If I wanted to update an Image, there would be an Update method on the image controller responsible for taking in the changes, validating, and dealing with the entity objects. Everything that had to do strictly with displaying information would be handled by a display controller like the before mentioned Admin controller. So something like:

As you can see, the Admin controller has something to show all users. The User controller has the methods for things like updating, creating, and validation. Basically anything that would change an image is on one controller. Anything for showing it on the main section controller. That is, a controller that embodies an overall concept like say an Admin section of a site or possibly a controller for viewing galleries.

The sequence of events (bad word choice…) would be something like:

Open Admin/UserList/
Admin controller uses User Entity to retrieve list
Admin View shows User List
User clicks delete button/link on Admin View
Javascript/jQuery method invoked to send id to User/Delete
User controller receives id
User controller validates id to make sure it is valid
User controller validates current user to see if allowed to delete
User entity Delete method invoked by User Controller
Result of Delete Method is returned by User Controller (JSon preferably)
Admin View displays the result

Treating controllers like classes (and the use of anonymous actions) allows a very clean separation of actions resulting in a nice logical layout. Beyond this, it also allows for a greater separation between controllers which means its possible to do multiple parts of the entire project in parallel.

Maybe this is just stating the obvious, something I’m pretty good at, but my hope was to give a quick over view of laying out controllers for those who are just starting out.

Do It Yourself

A question came up about an earlier post on how I construct my grids shown in a few examples.

Now as you can see, it looks like a table, acts like a table, so it must be a table right? Well it isn’t. It’s actually done with divs and styles, something I’ve worked hard on getting right since moving to MVC.

I’m not bagging on the question asked because I’m probably a mutant and the only person that thinks the way I do (and have written below). I just have a philosophy that if you can do it yourself, do it yourself.

For starters, I’m not against new stuff, I think that’s pretty obvious. I’m also not completely against third party stuff seeing as a lot of my newer posts deal with jQuery. I do, however, avoid third party tools I don’t need, namely grid builders or things of that nature. I figure that if I can do it myself, I’ll do it myself. This kind of hits on the debate of using Visual Studios’s drag and drop feature for designing pages or not. Sure it’s easy and for the most part works, but you are really doing yourself a disservice. Why? Because most of the time you can get away with it, it’s those few times that it just won’t do what you want it to do that kill you.

When you use helper tools, you could be cheating yourself out of knowledge

Now I’m not saying that you should develop your own tools for rendering 3d graphs. Some things you just don’t have the time or the ability to create, but when it comes to simple things like markup, do the work. The knowledge you gain from this is substantial. Hell, I used to hate style sheets. I used to hate javascript. Quite frankly, they were a pain in the a– at first. However, taking the road less travelled has given me a new perspective on both. I no longer fear them and in fact would rather just type the markup out myself than trust some third part thing that I can’t fix when something goes wrong. I know that if I have to create a quick mock up that looks like the real deal, I can do that with notepad and a browser. I know that if I have to teach someone how to use style sheets or javascript, I can do that without just telling them to go to some page or to use some random tool. I have confidence in my knowledge.

More time now, less time later.

Now I know in Perfectworld, there is always enough time allotted to doing what needs to be done. In Realworld (Not the stupid MTV show) everyone is running around, heads a blaze. So the biggest excuse to not learn proper markup is that there isn’t time. A company isn’t going to pay you to learn when things need to be done. Well sure, but flash forward a couple months when someone tells you that you have to adjust the grid you didn’t build yourself to add something you have no idea how to add or else the world is going to end. Last thing that person will want to hear is “It can’t be done.” In fact, most business people have some crazy allergic reaction to that phrase that causes them to turn really, really red. It’s weird but happens a lot. At this point you can either:

Laugh and lose your job.

Go on the forums and hope there is a solution.

Die a quick and painful death.

Always expect people to want 20% more than what was originally written. Unless you have one of the best project managers that says the phrase “Work request form” on instinct, you will run into this situation. That’s where doing it yourself comes in real handy. It may have taken you a while to figure it all out, but you will for certain be able to fix the issue quickly.

You never know when you’ll actually have to know how to build things from scratch

Tech Interviews. When looking for a job, you’ll probably run into these. Best way to be prepared for these? Have the real world knowledge. How do you get that? By doing a lot of the work yourself. I have been through interviews where I was given a simulated work item and told to produce code for it on the spot. Some of it had to do with the actual markup needed to display the data. (This was before MVC days, WebForm stuff) The people were far more impressed that I was typing out the mark up than if I had just done drag and drop stuff. Why? Because there is a stigma, fair or not, that drag and drop people are displaced VB Weenies, and the real programmers don’t bother with it. Knowing how to hand code mark up on the spot is far more impressive than using visual tools or completely blanking out because you’ve had to rely on third party software.

At this point I realize I’ve mostly talked about markup, but this whole idea extends to a lot of the programming world. Digging in and forcing yourself to do the work will substantially improve you abilities over time. If you can’t do this at work then find some time on your own to work on a side project to learn. Build your own error handling system. Build your own pager creating method. Build your own Url creating method for MVC. I promise that you will be in a much better position.

Final Note

You could argue that coming to a site like this and using copy/paste is against my spiel. Fact is, I’ve copy and pasted plenty of code to get to where I want to go. Difference between this and third party tools is you can learn from what you copy and paste. Actually I would argue that you have the responsibility to learn about what you are copying before you do anything with it. If you copy AND you take time to understand what you are copying, that can be just as helpful. If nothing else, it’s better than just using some third party method.

jQuery, Hidden Elements, and Why At Times I Hate It

So this is your situation, or at least it might be someday if you use jQuery:

You have a comment area that allows a user to view comments. Now this comment area is created using javascript (Read jQuery) only. When a user clicks on some kind of pager, a method is called to get a list of comments and recreate the comment table. Now you would think it would be a good idea to hide the table, recreate it, and then show it. Sounds like a decent way to go. So you try something like this:

  ...

  jQuery(commentTable).hide("slide", { direction: "up" }, 200 );

  ...

  //Get the comments and call a method to build the table.

  ...

  function buildTable(commentList, commentTable)
  {
    ...

    //Take the list and iterate.  Create a row

   ...

     jQuery(commentTable).appendChild(someCreatedDivRowWithAComment)  //BOOM

   ...
  }

Then you run it and bam you get an error saying that basically commentTable doesn’t exist. Now if this were WebForms and you did some kind of visible=”false” you would know that the markup for that table wouldn’t exist. However, in javascript style=”display:none;” doesn’t remove the element from the markup, it just hides it from the viewer. If you look at the source (Provided it’s not dynamically created) you will still see it in the mark up. So what’s the deal?

Well for some reason the creators of jQuery decided that there is a difference between a hidden element and a non hidden element to the point where you have to change your search (the jQuery() method is basically a search that looks for the element within the parenthesis) by adding on a “parameter”.

  jQuery(".someElement:hidden")

So if you do use the hide() method (Or fadeOut for that matter) you have to use the :hidden addon to find the stupid element. This can cause a big problem when things aren’t timed correctly. What does that mean? Well that 200 value I have in the hide method, that’s the time I want it to take to hide the element. Far as I can tell, and I’ve done some testing on this, the element is not :hidden until the animation completes. Which means there are 200 time units where it is not :hidden. Now if the time that it takes to get your comment list and start building the table is less than the time it takes to hide the element you’ve got an issue. Or conversely, if the 200 time units are up and it is now hidden, you’re really screwed because the normal search won’t work. You can try something like this:

   if(jQuery(this).children(".categoryBlockContainer").is(":hidden"))
  {
    categoryBlockContainer = jQuery(this).children(".categoryBlockContainer:hidden");
  }
  else
  {
    categoryBlockContainer = jQuery(this).children(".categoryBlockContainer");
  }

And this works ok most of the time, but you still might run into a situation where it’s still trying to finish the hide animation. Beyond that, it seems kind of asinine to have something like that in the code. It should find the element at all times, hidden or not.

This really kills the whole idea of animation.

Between this and javascript’s bizarre variable scope, I’ve had some thoughts of changing my profession.

To Async or Not To Async… That is the ReWritten Cliche Quote.

One of the things I’ve been wondering as a of late, besides why Micheal Bay still is allowed to make movies… and no money is NOT and excuse, is whether it’s better to just load and entire page and hide/show stuff on some click OR only load what’s shown and have said click handle loading the stuff through Asynchronous Calls and Json.

I bet that made sense!

Here’s the situation, I have a blog thing I’m working on and it allows for multiple blogs per site. The “splash” page, if you will, looks like this:

And when you click “Newest” it looks like this:

As you can see, Newest brings up a pop out div thing that shows the latest post.

Side note, I was going to have it just show the first X characters of the post as a teaser, but turns out that if there is any broken HTML because of that, IT’S A HUGE PAIN TO FIX. Something like <div> this is something that <di… OH SNAP THE DIV IS BROKEN! ALERT! ALERT! So this was a “solution”.

Originally I had it loading the needed post in it’s respective pop out div and just hiding all of them. Then it would show the post when the Newest “button” was clicked. Then it dawned on me that this might be silly since only one is going to be open at a time. Why send the client a ton of unneeded html? So, I moved on to using jQuery/Json to grab the needed post data when the Newest “button” is clicked. Then I just populate the pop out div with the returned information as it opens… or whenever it gets back to the client. Can’t always assume it will be there immediately. Interweb can be slow at times.

Anyways, this brings up an issue: Am I better off with the first or second solution? Given that all things are equal, it seems like a better idea to have the jQuery solution due to the fact you aren’t sending useless html to the client. This will most definitely help with initial load time for the client. Only problem is, that jQuery method is run every time one of the Newest “buttons” is pressed meaning you could have an infinite amount of requests per person. I suppose this is a matter of gambling really.

Do I go with full html and because I assume the user will look at all the latest posts anyhow and therefore cut down the needed requests?

Do I go with the jQuery method because more often than not, users will not look at all the latest posts OR at least will take some time in between the Newest “button” pressing so that it’s ok there might be a ton of requests over time?

At this point I think the second is the way to go, but it’s most likely situational. Time will tell.

What I Hate About Programming

Lately I have been screwing around with creating a blog framework using MVC and jQuery, the former being more troublesome from a design stand point. For example, The use of controllers and actions can cause a great deal of second guessing. Do I put all the admin view attached actions, like one for viewing a list of posts to select and edit, on an Admin controller? Do I have a Post Admin Controller and a Comment Admin Controller? Should anything having to do with Posts be on one Post controller and just seperate the actions based on attributes? (As in MustBeAdminAttribute as opposed to MustBeLoggedIn) After all controllers are about grouping things, but how the h— should they be grouped? Of course, that’s a sort of gray area an subject to debate. The problem is I can’t help but think not matter what, I’m making the wrong choice. Why? Mostly because I know I’m not a super programmer.

Now this isn’t going to be an Atwood, back patting, I’m so good I know I’m bad kind of post but something has really occurred to me more and more lately. As I’ve gone deeper and deeper into things like Entity Framework, MVC, and jQuery I’ve only been left with the feeling that someone else, somewhere is doing this a lot better. Maybe it’s because my lack of experience with them, maybe it’s just a self depreciating nature thing, but it’s also having access to too many good programmers due to the plethora of them on the internets. Yeah right, that’s a bad thing? Well it kind of is. It’s tough doing anything anymore when you know there are people far better than you doing a far better job. And with the advancement of information sharing, you can’t help but find proof of that. With that comes a certain guilt that you aren’t the top of the food chain and in fact you just might be a programmer the other better people complain about. That’s right, you. Someone at this very moment is straight up banging his/her head against a desk because of something you wrote.

Some would suggest this is the sign of a good programmer. Someone who is never completely happy with his/her performance. F— that, it just plain sucks and makes what can be enjoyable an epic pain in the a–. No one wants to be that guy, you know the one that names every variable with numbers (v1 + v2 = v3) or has one gigantic method that does everything. Problem is, this is all relative. One person’s perfection is another guy’s multi purpose stored procedure that runs 10 different query using a switch and a passed in string. Code perfection is in the eye of the beholder. And by now we all know there are plenty of high end beholders.

What does that mean? You can never win at the game of programming. Read it again. You can never win at the game of programming. That is unless you are beyond a doubt the sharpest bulb in the bunch. For the rest of us chumps, it’s grin and bear it time.

That’s it. That’s the answer. Suck it up. Don’t like that answer? Refer back to the answer. Fact is, you’ll never be perfect and if you were, chances are you wouldn’t be reading this nonsense. You’d be out in the middle of the Gulf of Mexico kicking it back on some island you own. For the rest of us mortals (Or dumb immortals), it’s time to join the Tool Fiesta. Start dancing, drinking, and accepting. I’m not saying that you can’t better yourself. Hell maybe you’ll be one of the top people out there… and optimistically thinking, considering this site, maybe you are (What the hell are you doing here though?). But you aren’t going to be perfect and neither is your code. However, sitting around and worrying about producing perfect code is just sitting around. Have to figure some code is better than no code at all right? Just lie to me.

Did Postback ruin the “web”?

If you’ve been reading my drivel as of late, you’ll know that I have moved full steam ahead with MVC, for better or for worse, ’till death do us part… or until MVC catches me shacking up with a much younger framework and sues me for everything I own. Either outcome, I going with it for a while. Why? Well I could name a couple reasons but the main thing I just like how easy it is to use jQuery with it do to how “RESTful” is it. Silly, I know.

Well I have put out some things about certain catches with MVC and it started to make me wonder about why I’m having so much trouble with certain aspects of the framework. It isn’t the modularity. I really like the controller concept. It isn’t the attributes instead of base pages to take on certain repeated checks (Say if the user is logged in), it fact I’ve embraced them. No the problem lies in the last few years of my short but uneventful programming career.

In the beginning there was ASP

I’ve admitted before, or at least I think I have, that I’ve only been doing this for about 7 years. I wasn’t the kid that started programming on an Apple II (E, C, GS, you can take your pick. Had them all growing up), I didn’t find programming those mini computers (You know the ones that basically had a strip of plastic that served as a monitor) all that much fun, and I surely didn’t sit around in my youth trying to hack into anything put in front of me. I just wasn’t that guy. In fact I didn’t start programming until around 2000 or so, the hey day of ASP. Now at that point in time, what a page could do was pretty limited. You could show tables, you could click links, you could post data to save. It wasn’t pretty but it got the job done. For the most part, web programming was just a step up from kiddie scripting and a small step down from VB Weenies. Fact was, it wasn’t very complex and site design reflected this. Sure there were a few that could push the limits, but the limits were pretty low.

You can cut a tin can with it.

ASP.Net… or at the time “.Net”. .Net was this almost mythical name that seemed to be used for everything from solving the complex page dilemma to removing that nasty “cranberry” stain from your expensive sheets that you can only buy in Sante Fe. At first people were sceptical, and why not be? Microsoft was pushing it as the universal key and at the time that seemed pretty impossible. Then people started using it. Sure it was messy at first. A lot of the people from the ASP walk of life either had forgotten how to program in forms or just never really learned. (Yours truly) Now all of a sudden there was a separation of mark up and code, and some crazy thing called post back, and wow what the hell are events? Classes? Double You Tee Eff? It was like this wave of excitement that web programming had grown up and it was the real deal. And it didn’t stop there.

Give a man an inch…

Well it didn’t take long for the over ambitious (IE Sales people) to start pushing the envelope of what could be done. Every time we reached what we thought to be a summit, someone would see if we could climb the next mountain… that happened to be twice as tall. After all it should be safe to assume that if you can make it up 10k feet, then 20k shouldn’t be that much harder right? All of a sudden “Can you do this?” had turned into “What I want is this” and for the most part it was possible. (Though ugly at first)

I want a page with data that I can edit.
-We can do that.

But I don’t want to be taken to another page
-We con do that

And I want it update when I save something without leaving the page
-We can do that

And I want it to seamlessly incorporate a bunch of different information from a million places and have it handle each part of the page differently but also have it handle all of this without leaving the page… and I want it done in two weeks.
-We can do that.

Of course this incredible feeling didn’t really allow us to think about the cost of all of this. Things like Viewstate, Session, gigantic pages with a bountiful of html, inability for smart phones to browse or at least load quickly, ect ect ect. It didn’t matter, because we were able to give the customer what the customer wanted: A Winforms program without the installation process. And over time, this has allowed pages to be so complex in structure that it you really couldn’t tell it was a web site if it weren’t for the browser.

Just because we can do a thing doesn’t mean we must… do that thing.

WebForms, as the cool kids cal them now, opened up a whole can of worms. They made it easy to create incredible complex pages with relative ease. And to do so they bent the “rules” of the web to allow for greater ease of development, at least that’s what you hear from MVC proponents (And REST people). MVC brings us back to the time when programming didn’t pervert the system, and at it’s core it isn’t pretty. Taken just as is, with the tools that the MVC framework has, the complex Web Forms we grew accustomed to are just not possible without a ridiculous amount of work. Heck a simple button press becomes much more complex in order to mimic a Web Forms post back. And that’s the problem… I’m trying to emulate something that MVC wasn’t built for and in a way could be argued that the web wasn’t built for: The post back. The Post Back is one of the key parts of Web Forms that allowed for so much and it really isn’t in MVC. I mean it could be. You could load up all the page/view functionality onto one gigantic controller but that kind of breaks one of the strengths of MVC: Modularity. Fact is, that little guy helped shape the way we think of site design and programming. (Not to mention viewstate but whatever) It allowed for so much to be done with so little effort. It gave us a bridge to winforms. For right or wrong, it gave us a solution and it also reprogrammed our future ideas.

Who has time for principal?

When conversing with other people about MVC, I had stated the whole “It’s the way the web was intended” line (Which personally I really don’t subscribe to because in a way I don’t care) and someone rebuked, “If it gets people what they want, then who’s to say what’s right for the web?” And I have to agree with him on that. I mean, it’s not like there’s life on the line here. If I move to MVC purity there will still be hunger, still be war, still be movies made by those idiots that brought you films like “Meet the Spartans” and “Disaster Movie”. (Although if Microsoft could solve that problem with MVC, I don’t think we’d have Web Forms anymore. Get on it Microsoft…) In the end, isn’t that what matters? Getting things done?

The beat marches on

So where do I go from here? If anything, I think the 800 gorilla is that I have to start designing web sites in a new way. Have to unlearn all of the things I got from WebForms and take myself back to the day when things were more simple. Even with advances with Asynchronous Calls, I still have to develop a completely different state of mind. Is this a bad thing? Time will tell. It’s possible that this is a fool’s errand but it’s also possible that use of MVC will bring forth sites with better structure and more reasonable functionality. After all it’s possible that post back derailed good site design.

Let it be noted

Before the comments about [Insert Javascript Library] start to pile in… HAHA comments on this site… Ok let’s pretend I get comments and the would be comments about [Insert Javascript Library]/Asynchronous calls(Let’s just call it JLA for short) calls, right or wrong I see JLA as a work around. It’s a way to allow for the complexity of said Web Forms without changing the MVC framework or relying postbacks. But even with those you still have a lot of unfun code that barely makes up for the loss.

Modern Programming: Anti-Evolution?

For a moment let’s just not bother arguing the merits of evolution versus whatever, and look at one of the basic ideas behind it.

Every one’s heard the cliche phrase of “the strong will survive”. Most likely it’s been in some movie you watched, some coach spouted it out, maybe you hear it from some business “guru”. Doesn’t matter. (Although there is actually a lot more since it’s not the just being strong but the best suited for the current environment ect, but let’s just play Sesame Street evolution.) Let’s go by the overall idea that those that have traits that are against survival will be removed… ie the weak.

The best code I’ve ever written was someone else’s.

Whenever you do something new, you run into problems mostly due to lack of knowledge. In the programming world, this is an everyday occurence provided you’re actually trying to learn. Can’t figure out how to make something work? Well just go search for it. No matter how new something is, most likely there are already people answering questions about it on a forum, posting it on a blog, or probably some site that is dedicated to it (Say like MSDN) that will give you an idea of what to do. That’s the beauty of programming today. But what about 20-30 years ago? What happened when you just plain didn’t have instant answers or dare I say it? No Stackoverflow. Well some people would be just fine. Those people would just plow through and figure it all out. They would go through whatever written specs there are on… paper… and get it done. They are the people who already have posts about it in their blogs now days before you even asked about it. These are the real programmers. Problem is, for every one of those there are probably 10 people who take what they have and run with it. Then for everyone of those there are 10 who barely understand it, just copy/paste, and post it somewhere. And for every one of those, there are ten that take that code and use it. And guess what? Most likely all those people still have a job. All of them.

The herd isn’t thinning

The question now is: How bad is this? Basically with the wealth of information out there, even the worst of programmers can keep a job that no way in hell they would have held 20-30 years ago. (How can I guess that? Because even 7 years ago when I first started really programming it was difficult to find things and that was with search engines.) With the demand for programmers being so high in so many places, businesses are almost forced to take on people who have just barely (Due to said search engines/copy and paste) made it because hey at least the person has prior work, so he/she must be good right? So the cycle continues, but in the long run most likely it continues in a direction contrary to evolution. Because remember, by my completely accurate and undebatable numbers, there are 1000 bad to every excellent. By that idea, and since the bad aren’t being removed, the amount of bad code out there is growing at an incredible rate and it’s being learned by new people. People who may not be bad but will be eventually due to the amount of horrible stuff out there. The bad are breeding bad, and it isn’t being stopped. At some slippery sloped point you have to wonder if there will only be mostly bad to learn from.

Those that are most capable of surviving in the present conditions will be chosen

So the whole “only the strong will survive” isn’t exactly the whole story. It’s not just strong but whoever is best suited for the environment. When we think of strong, we think most rugged, toughest, most able to surive encounters. However, in the evolutionary sense this isn’t true. If it were, all dinosaurs would have been like this almost mythical bad boy. Problem is things like food availabilty, ability to avoid predators, hell even resistance to sun exposure can all factor into what is really “strong”. The point is, those who are chosen are best for the environment they live in. Now lets take the 1000 bad coders to every 1 excellent one. With that in mind, most environments entered into are going to be suitable to which group? The bad ones. A lot of us have seen this. Started work at a company that the code was just dreadful but the 3 guys that have been there for years and the one dude that was hired in a week before you are all happy as a pig in… well anything. We try to change things. We try to move things forward, but in the end we get burned out and leave. Guess who replaces you? The guy who works well with the other four. In fact, this is another part of evolution is that if two groups of the same animal are split by something, say a new river, the two might in fact eventually become incompatible. Think about it, a company that has strong programmers and weak ones that becomes taken over by the weak will eventually spawn a whole new type of programmer and programming shop that it completely alien to a decent programmer and would allow itself to continue unstopped. At some point, slipery slope full on, there may end up being way more bad companies then good and the good programmers may get weeded out.

How do I know if I’m the strong?

Fact is, you probably can’t. Some people know it because they work for high end companies like Google and Microsoft. The rest of us mortals don’t. I think that is why this career has frustrated me at times actually. I can’t really be proud of what I’ve done because I’ve never been fired for bad code. I’ve never been released for writing bad programs. Hell I’ve never even been pulled into an office. You would think that means I’m doing something right except I’ve never known anyone who has. And I’ve had about 8 jobs over 7 years(All due to contract work or companies going under… Let me tell you, I’ve was on a streak of joining failing companies for a while), so I have my feel for bad code and bad coders. None of them were fired or let go because of bad code. And companies keep hiring in bad people so I’d have to believe that even if someone was let go, that person would find another job eventually. Hell, go to somewhere like Chicago, and you practically have to shoot someone to get fired because companies need people so badly.

Better than being dead.

So maybe its a good thing. Since after all I still have a job, I still get paid well, I still have some security. But in the long run, is this a good thing? Can programming as a whole grow as this situation continues? Everyday it gets easier and easier to be a programmer. I can’t imagine that’s going to change. With tools like jQuery, StackOverflow, Google, and any other way to help people with kid’s gloves, it’s hard to think that things are going in the right direction.

Last note

While writing this I couldn’t help but realize that this my be riddled with hypocrisy. After all, how do I know if I’m not one of the bad people? Sad thing is I don’t.

What about you?

ASP.Net MVC: Is the Use of jQuery/Asynchronous calls a Must?

In this wonderpost, I questioned the use of jQuery in the mind of the purist MVCist. (If that’s not a word yet, it is now and I expect royalties.) Now I’ll flip it tool style and ask it from another direction: Can MVC survive without jQuery?

Here’s the situation: I have a site that I made a while back (Basically a phone friendly chat room emulator) that was kind of experiment on a couple levels, one being the use of Entity Framework and WebForms. (It’s here if you are curious… right now you have to make an account though. Never got around to allowing non logged in users.) Another part was to see if I could make a multi phone compliant page that had to be fast and work on as many phones as possible. (Anything with a browser at least) And had to be touch friendly. (No links, just buttons)

A week back I decided, after trying to make new sites with MVC, to take an existing work and really give MVC a rugged test. Eythere was just that site. Now personally I thought this would be pretty simple since MVC seemed really good at simple, non business sites. What could be more simple than a chat room emulating site that has no javascript? (Aside from whatever Javascript WebForms use for postbacks) I mean in the end, it’s just a bunch of buttons right?

Yeah turns out what those buttons did was at the heart of my issues. You see, with WebForms, everything done on a page is meant for that page. Sure you can defer how things are handled from the page to another tier, but the action itself belongs to the page. For example, say that a user wanted to make a room a favorite, well there’s a button named favorite that he/she clicks to do so.

In webforms, the Room.aspx page would handle the Favorite button click and the current user’s favorite list would have the room removed or added depending. But the call to the add/remove would be handled by the button’s click event and then the page would be reloaded. Something we in the know call “easy”. (Like that word? Use it. It’s free because I’m such a nice guy)

Now with MVC it’s a whole new ballpark. With controllers, it becomes of question of what controller should handle this. It could go onto the room controller, but in the end it deals with a user and adding something to the user. So it’s fair to say that this is probably a job for Superman if Superman happens to be a UserController or you’ll most likely end up repeating code.

Now the issue: How is this handled? Whether link or button, something has to be posted to the user controller. Posting to the controller means that the controller, on finish, has to create a model and send it to a view. Well this kind of sucks doesn’t it? The user clicks the + Favorite button and bam is taken to a whole new page.

SURPRISE IT’S BEEN ADDED TO YOUR FAVORITES!

Not what I would call fluid. The other thought it to have a redirect, which in the end is more fluid in that it takes the user back to the original page BUT with that you have to send a lot of information back and forth. After all, in MVC a lot of the information for a given “page” is passed using get. So for instance you have a room with a roomid and a page number and a count of items to show and possibly a sort you’re looking at:

/Room/1/?pageNumber=1&amountToShow=5&sort=Date

Which means all of that has to be sent to the User controller in order to save the state, has to be put in session/some kind of user cache, or you just send the entire url. In any case, something has to be tossed around for this to work. More seamless than the other way but it is a lot of work for something so simple.

When it comes to ease of UI design, jQuery/asynchronous operations are a must.

Something I think that the MVC idea fails at it in a UI sense it was makes it strong in a programming sense, logical separation of tasks. Right off the bat, I hated the way WebForms handled AJAX “web methods”. Having to repeat methods per page so they could be “registered” was ugly and a pain. MVC and it’s separation/REST ways makes asynchronous calls so easy. However, what used to be a simple operation in WebForms has now become cumbersome without outside help. Straight up, it seems impossible to do non drill down design without using jQuery or some kind of javascript library equivalent without killing the separation that MVC seems to embrace.

Why is this a problem? For the most part it isn’t. Most people aren’t going to try something like EyThere (Wouldn’t recommend it, it was a pain) since how many people create sites with multiple phones in mind? However, it does serve to show what seems to be a glaring annoyance with MVC. Either use asynchronous calls or just sink.

Entity Framework: Am I Just Being Stubborn?

Before I started using The EF, I had a couple years of use with LLBLGEN and about a year into NHibernate. I started dabbling with Linq to Sql for a bit but found it a bit lacking (As it was new, go figure) and decided to go forward with Entity Framework due to the fact that I really like Linq, and although LLBLGEN had Linq integration, I figured the Entity Framework would be the first out there with any changes in Linq. (Not exactly sage like foresight) And at the time HQL was still the thing for NHibernate, and although it’s not a bad design, it’s a nightmare waiting to happen since you can’t get a compile time check on the HQL strings. So it seemed like the right idea at the time, and despite what I’m about to write, it may still be.

I saw a lot of people bagging on it saying that it was missing this feature or that feature. Most people were annoyed that there wasn’t built in lazy loading. Some were annoyed with the fact that the classes are coupled to persistence. Others just complained because it wasn’t [insert your ORM here]. I on the other hand championed the cause with this in mind:

It’s just a framework. The tools are there do what you need, you just need to build it.

Take as is, the word framework is just that. It’s just a start. It’s that point where a house is just a bunch of wood nailed togther. You can’t really live in it as is… well I suppose you could?… but it has what you need to produce a complete house. Just takes a little time and effort. You can already see where this is going. After all, I’ve already figured out I like pain.

So the first issue I ran into was the context itself. You see, I was already used to multiple calls to the database being done with one “connection” and by that I mean not this every time I wanted to get something:

  using(var entity as ToolEntities)
  {
    entity.Tools.Select(...)
  }

Mind you my syntax is more psuedo in that example, but the idea was simple; It was going to be annoying to have to do that every time I wanted something from the database. So after hours of thought and some research, I came up with a solution that would open one “connection” per request that all queries within that request would use. Ok so that was out of the way, and I can’t compain since after all:

It’s just a framework. The tools are there do what you need, you just need to build it.

The next thing I ran into was lazy loading a many to one or one to one property. I had already seen stuff on many to many or one to many loading. Simple method .Load(). To my surprise there wasn’t such a method for this (Not directly at least) so I was stumped. Time to go back to LLBLGEN? Hell no, mush on. And mush on I did. I found the .Include method:

  context.Tools.Include("Favorites")

Boo yah, and I’m back in the game… or was for a little bit until I realized that this is pretty bad since Include loads the whole object you are including. This could be ridiculous if you have an object with 10… 100… ONE MILLION many to one or one to one properties. So once again, hours of thought and research later I came up with a solution that was eh good enough but wasn’t exactly what I’d hoped for.

It’s just a framework. The tools are there do what you need, you just need to build it.

Another issue I ran into was a creating an IN clause method. Contains just doesn’t work with Entity Framework. Straight up, flat out, no can do sir. So again, with time and research I found a way to do this (Which I haven’t posted yet due to the fact I didn’t come up with the solution and I can’t find the link I got it from). Of course there was the order by situation, oh and this gem, and this that I can only describe as a god damned mess. Really? It’s in the context yet you still have to run a query on it? Really??

I’m not going to quit on Entity Framework just yet but after a little introspection I have to admit that I’m close to responding to my own righteous:

It’s just a framework. The tools are there do what you need, you just need to build it.

With a big :

Go f- yourself.

This whole situation reminds me of a saying:

If you’re in a poker game and you can’t figure out who the patsy is, you’re the patsy.

It doesn’t take much imagination to apply that saying to my situation and to be honest I might be falling into the same situation with the MVC framework. Time will only tell with that. Although at least with MVC I have plenty of patsies with me. I think with Entity Framework, I might be the only one losing money.

Are jQuery and Asynchronous Calls against MVC?

This is something I started to think about the other day as I have been diving deeper into MVC. In it’s purest form, at least to what I understand, is that the whole idea of MVC is to have a separation between information handling (controller), information delivery method (model), and the information presentation (View). What this means is that the View itself should only be around to display or return information, but that’s it. Have a form? Great, here’s the information you need to fill out and I’ll send it on it’s way. And even with that idea, the View itself doesn’t really send anything. It just passes what it knows off to the model and it’s back in happy land. (The view gets nervous sometimes… performance anxiety) The whole system works well in actuallity, it does what is expected. There are no events simulated and possibly tangled. There’s no smoke and mirrors when it comes to the display and what the user is seeing. I want a grid of users? Here it is. I want to edit this user? Great! I’ll take you to the page that does that. Life is great and wonderful.

But wait, here comes jQuery, Json, and Asynchronous Calls. Now I can do crazy things with the view that I could never do before. Remember that grid of users? Well you don’t really have to go to another page to edit. Hell, just click this link and a form can appear to take in what you need to change. Even better, the grid itself will change and allow you to edit any row you want, and when you’re done the grid will come back all new an refreshed. What a crazy party this is now. Kind of sounds familiar right? Yeah WebForms. With these three helpers we’ve now cut out the middle man in the Model and passed the savings onto you. Essentially the whole idea has been chucked and jQuery has allowed us to invoke the same event model WebForms was chastised for. In fact, you could go to the logical end and have one page once again that controls everything. The View once again has the power much like it did in WebForms (provided you look at the Page and code behind being more like a View than separate entities). Isn’t that the whole thing we were trying to get away from?

I suppose you could make the argument that no one is putting a gun to your head to use jQuery for anything other that simple things like UI manipulation (date pickers, sliding controls, drag drop, ect) but that wouldn’t be the situation being argued here, now would it?