Posted: 03/05/2012 @ 11:38
In just 2 weeks time I'll have been working at UK-based cloud solutions provider Outsourcery for 3 months - the time has flown by - and I'm pretty comfortable already. The department I work in seem pretty keen on ASP.NET MVC - which I have never really used properly in the past. I've messed around with tutorials, but never used it in anything "real". That is, until I started my new job.
And I can't say I'm a fan. In fact, I think its rubbish. Up until now I've perfected the way I structure regular WebForms applications. I don't develop WebForms applications with massive ViewStates either. I've created extremely robust, lightweight WebForms applications. Sure it's easy to create bad WebForms applications (which seems to be a major argument of most MVC enthusiasts), and Visual Studio makes it even easier to create bad WebForms applications. But you can get bad applications written in any technology.
The reasons I'm about to list, whilst probably not that important to some, are to me. The point of this post is more to point out the fact that MVC actually removes functionality that made my life easy as a developer.
Each point is listed in order of importance - starting with #1 being the most important...
Want a site with public areas as well as Integrated Windows Authentication? You'll have a hard time with MVC!
Possibly the deal-breaker for me.
Due to the structure of MVC not relying on folders like classic WebForms, you have to handle security on an application level, rather than letting IIS deal with it for you. This is a bad point in itself, but the worst is to come.
With a WebForms project, you can create folders in your application, and stick a web.config in the folders you want to protect. You can have most of the site accessible by the public, save for one folder that you want to people to log into (an Administration area, for example). Tell IIS you want to use Integrated Windows Authentication, and you can restrict access to folders based on Active Directory or just the local computer's groups, or even restrict down to the specific user.
If someone uses a browser like FireFox then a login prompt is displayed - enter your credentials and off you go. Use Internet Explorer, and if logged in as that user already, you don't have to supply your credentials again. Simple.
My first project in ASP.NET MVC required a public site with a simple admin area with access to some pretty basic CRUD functionality. Due to the way Controllers and Views are laid out, this meant that I had to implement the security on an application level.
I ended up attempting to do a halfway house - to control access to the particular Controller I wanted to protect (AdministrationController), I implemented my own class attribute that inherited AuthorizeAttribute. Now if a user were to try and access that controller, unless they were authenticated by Windows, they would not be given access.
Great, you're thinking - that's what I want after all. Not quite. When accessing a controller that someone needs to log in to view, if they're not logged in already, IIS doesn't challenge them for their credentials. It just says "You're not logged in". Because it's all handled on an application level. I needed some way to prompt them for their credentials, and .NET does not provide such functionality. There is no "ChallengeUser" type of method. I needed a way to allow them to log in, and then check at application level via my custom AuthorizeAttribute whether or not they had the correct permissions.
So after some head scratching, I set up a folder in IIS called "Login", that I restricted access to save for one particular user group and put in that folder a HTTP Redirect via IIS to a view using the AdministrationController. And it worked - you'd go to /Login, the browser would prompt for credentials, once logging in correctly, the user would be redirected to my AdministrationController, and the custom AuthorizeAttribute would allow them to perform actions in the controller.
Quite a convoluted work around, I'll admit. But it was the only way I could do it, save for having a LoginController with associated views to authenticate the user completely on application level.
However, this method I've explained was too was flaky. Strange behaviour ensued - at random intervals .NET forgot the fact that the user was authenticated, and would redirect them to the "you are not logged in" page I created. If you went to /Logon, .NET would again suddenly remember, and redirect them back to the default AdministrationController view.
In the end I created a Login table in my database and created a LoginController, with a simple view that requested the user's credentials. So I handled it all on application level. Set a session variable to check if they were logged in. The cheap and cheerful way - certainly not elegant, and the method of least effort - but at least it works.
So that is my major gripe with ASP.NET MVC. Better support needs to be added with regards to Windows Authentication.
.NET Code in View Mark-up
Not really a functional issue but more of a personal preference - to render out tables and controls in MVC, you have to stick your .NET code in the mark-up. There's no code behind. It looks messy. Real messy.
I love the code-behind model because everything you create declaratively is available on your code-behind - it's easy to debug, it's easy to access the controls on the mark-up via their IDs.
All XML mark-up is in one file, and all .net code in another. I thought MVC was meant to be about separation - it certainly doesn't seem this way for me.
Where's my data binding?!
I like ASP.NET WebForms data binding. It saves me lots of time. If I set up my data sources in the correct way and plug them into controls such as ListView, there you go - instant CRUD functionality. I don't have to spend my time worrying about doing all the ground work - that's one of the best things about ASP.NET WebForms. I can focus on the more complex logic elsewhere.
I agree, data binding can be confusing to begin with - but once learnt, and if done correctly, it can save time.
In ASP.NET MVC however, I have to do ALL of this myself. I have to render out each row of a table for example, and I have to create an action for each time I create/update/delete.
And to those people that say "But! But! You get fine control over what is rendered to the browser!" - this is true, but you can completely customise the ListView - I've worked with this control a lot and always been able to do everything I've ever needed.
Self-contained User Controls are USEFUL
You can have "User Controls" (.ascx files) in ASP.NET MVC - but due to the Controller-View model, you can't for example, have a user control that accepts some database ID as a property, and displays data based on that ID. The data has to be in the ViewData object to begin with, passed from the Controller. All this logic which should be self-contained has to be worked out via the Controller action you're initially calling, for the main view.
I guess I'm more just a fan of programming with objects. It's more intuitive to me as an OO developer. I like the idea of being able to drag a custom control onto a page, and for it to have its own functionality and act on its own.
MVC does not allow for this.
Bizarre Default Caching
This is more something that I haven't gotten to the bottom of - if you know the answer to this point, then please feel free to contact me, I'd love to know the answer!
By default with ASP.NET MVC projects I have noticed bizarre caching issues with Internet Explorer only. For example, was using LESS to change some styling on a view. I already had an existing IE window open, changed some styling and did my usual web-development thing of pressing CTRL+F5 - and the content would not look any different, despite the changes I made to my .less file. For some reason, it was caching the old .less file, even though I had asked for a complete refresh of the page. Closing the browser completely and opening it again solved my problem in the end - but this doesn't help my way of working in any way.
Yet the strange thing is, I did not get the same issue using FireFox. Which is what makes this issue especially bizarre. So when developing ASP.NET MVC sites, I always make sure to use FireFox for development by default.
I don't get this problem with regular ASP.NET WebForms projects - why with MVC?
So overall, not a great experience. Sure - I can see the benefits of MVC, separating out the business logic from the presentation layer is a good thing - only all the controls provided by the ASP.NET team can't be used, and it takes 1 hour to complete something that in WebForms would only take me 15 minutes.
ASP.NET MVC gives me nothing extra over ASP.NET WebForms - and in fact removes functionality that I relied on.
Tags: asp.net, development, mvc
Posted: 06/01/2012 @ 19:42
The following article is actually one from my previous blog at xanni.es (now redirects to here), as mentioned in a previous post.
It's not a bad article, talking about an free software package called Cobain Backup. I still use it to this day, so I thought I'd copy the article over to bulk out my new blog here at Code47 :)
I've edited it a bit, but it's mostly the same. Just want to keep my recommendation out there.
Cobian Backup is probably the best backup software I've ever used – and best of all, it's free. In fact, I was so impressed with Cobian Backup that I decided to write this review on my blog (and I haven't written here for a while, either).
Although my main function at my company is 'Software Developer', occasionally (*cough*) it falls to me to look after the various computer systems within our small organisation's office – the on-site file and mail servers, the web server, our database server, the M.D.'s computer, as well as any other machine running Windows.
Since I took these responsibilities on, I introduced a backup policy to safeguard, well, everything. Everything from our SVN repository to our Exchange mailbox database.
I had the company invest in a Quantum GoVault, after reading various reviews, it seemed the most sensible choice; it wasn't overly expensive, and it is at the end of the day, all it is is a fancy metal dock for small, rugged, removable hard drives, and works without any extra special intervention from support software (i.e. once you plug it in, it shows up as a removable disk drive). The package came with 2 40-Gig 'cartridges'. We also invested in another 40-Gig cartridge for 3 weekly generational backups.
Once we acquired our GoVault, I realised that the backup software that came with it for free wouldn't run on Windows Server 2008 (I believe the product is a few years old – this is probably one of the reasons it was so hard to actually find an affordable supplier with one in stock – in the end we ended up going with PC World Business, of all places! I know, not my usual choice of store, either), which was a bit of a shame, so I was forced to look elsewhere for a solution. Seeing as the GoVault appears simply as another drive in Windows Explorer, this wasn't too much of an issue.
After having a poke around, and reading various pages and forums, I came across Cobian Backup. Now, there is a hell of a lot of free backup software out there, however, almost all of them suffer one major flaw; most were designed for Unix based operating systems, not for Windows, and have been ported (sometimes very shoddily) to Windows. I especially hate it when software requires you to install crappy Linux GUI frameworks.
I even considered the in-built, Windows Server Backup. But, unfortunately, this was the worst of the lot! Windows Server backup is good, if you just so happen to be a medium-large company with a large IT budget to work with, and if you're happy to work the uniform way Microsoft want the regular IT Administrator to deal with backups.
For example, with Windows Server backup, you can back up individual files and directories, but not to removal media. And you can only do it as a one off, and not a scheduled backup (one question: why?). It seems to want you to have an entirely separate drive for your backups. It's very inflexible with regards to how and when you back up (I think the only option was once a day). So yeah, the worst option really.
Cobian Backup was written for Windows, therefore it feels familiar. It's easy to set up; installs as a Windows service, as well as the Volume Shadow Copy service (more about this below) and provides you with a straight forward GUI to interface with the services.
Personal noteworthy features of Cobian Backup:
- You can backup individual directories or files as well as backup to or from FTP servers
- You can choose to encrypt your backups easily – simply select your favourite encryption algorithm and supply your keys
- You can have backups compressed in the good old familiar zip format (or 7z)
- You can choose different modes of backup (i.e. full, incremental, differential)
- You can configure your own highly customisable events to run either before or after the backup process
- You can configure Cobian Backup to email as many people as you like once the Backup has completed, along with the log file, so you and others can quickly check to see if everything ran smoothly
- The scheduling is extremely flexible – I configured our weekly backup to run every Friday at lunch time (our “server maintenance hour”)
- You can apply an array of filters to the directories you include, to explicitly ignore certain file types, or explicitly include only certain file types
- Backups are stored in an extremely sensible way, with sensible folder names, and not in a weird file format that lumps everything together in a strange way. The files are just copied 'as is' to the destination (unless you choose to compress them with zip, in which case they're all stored in zip files - of course)
- The Volume Shadow Copy Service (VSCS). Now I know this is included in Windows Server Backup, and is probably included in many other backup software packages, but it's the first time I've seen it. When implementing backup policies in the past, I often found that one the major annoyances was trying to backup a file, only finding after it had run overnight or after you left work, that a certain file couldn't be backed up because it was in use (for example, an SQL Server database, or an Exchange mailbox database, that has to be mounted, and is therefore constantly in use). The only way around this would be to stop the service using the file, back it up, then put it back the way it was. This, obviously, isn't a fantastic solution, especially when I want the process to be automated, and not have to do it manually at midnight during the week.
The VSCS solves this issue, by taking a snapshot of the files that are to be backed up, then backing these up instead, so that the original files are left to be used as they were. It basically means there are no interruptions, and everything gets backed up with no issues!
My only gripe with this is, the VSCS cannot be installed on other computers and called upon remotely. The VSCS can only be installed on the machine local to Cobian Backup. This was an issue for me especially, as our Exchange mailbox database is on our mail server, whilst the GoVault is hooked up to the main file server. This isn't a huge issue however; all I did was to install a copy of Cobian Backup on our mail server, and have it back up the Exchange server mailbox Database to our file server an hour before the main backup on the file server is to occur. Then, have that back up backed up with everything else.
So, that's it really. I don't have much more to say, other than if you're looking to backup your servers for a small/medium sized business, just don't automatically go for the expensive option because of support or big names (in fact, I think I'd always keep away from names such as Symantec and Norton, given how awful the anti-virus packages are to use); Cobian Backup probably does everything you need, and more.
Tags: backup, misc, sysadmin, windows
Posted: 02/01/2012 @ 18:17
After much Googling, and avoiding some very dodgy looking websites, I finally settled on aspnethosting.co.uk.
By the looks of it, this place offers the best value-for-money deal on asp.net hosting - even compared to my current host, phpwebhosting.com, which is $9.95 a month, which translates (at the moment) to roughly £6.41.
Obviously at phpwebhosting, I can't host ASP.NET applications, and seeing as these days I do next to no PHP development and lots more development (even personal stuff) in .NET, I signed up for aspnethosting's "Professional Plan".
It's normally £5.00 a month (which is already cheaper than phpwebhosting), although if you use the lifetime discount code they are currently running (aspnet_25), you can get ASP.NET hosting for a mere £3.75 per month. This package includes:
- Up to 99 email accounts
- Up to 2 gigs of HDD space
- Up to 10 seperate websites
- Up to 2 hosted domains
- Up to 2 SQL Server 2008 databases
I'm impressed so far - managed to configure my application and get it working with ease. All on the first day, in under an hour.
I'll be running my aspnethosting account alongside my current phpwebhosting account (which I currently use for my personal email - and another personal website), and, if everything holds up as it should, I think I'll be switching over to aspnethosting permanently.
Tags: asp.net, hosting, windows
Posted: 02/01/2012 @ 15:51
So this attempt 2.0 at keeping a technical blog.
I wasn't happy with my existing blog at xanni.es - it was meant to be a general-topic blog, from code to album reviews - to well, anything.
With Code47 I plan on keeping the scope to my work as a Software Developer - that's the plan anyway!
I didn't keep my previous blog up to date. It was a clunky PHP Behemoth with a WordPress front-end that required updating every 2 weeks. Not meaning to bash PHP or WordPress - but the "update" function accessible via the Control Panel didn't ever work, and I had to mess and faff around with FTP to update everything - when well, I didn't need everything WordPress offered anyway.
It was difficult to customise, and I didn't have as much control over it - not as much as I'd like anyway. I generally found it hard to work with.
So I made my own site - with its own blog!
Everything you see here, from the layout, design and backend was implemented by yours truely - and I'm quite proud of it.
It doesn't even have a database back end - it runs entirely on XML files which are cached in memory when the ASP.NET 4.0 application is first started - and all the articles (which, let's face it, arn't going to be very big in terms of size) are held in memory for the lifetime of the application.
So - in theory - it should serve articles quite quickly. No database connections should also make for an easy deployment.
It's also simple to update - at least for me - nope, there isn't an Administrator 'Control Panel' - I can just alter the XML files as I see fit, then rebuild the 'Article Cache'.
Anyway, I think that's enough for the first introductory article - if you want to know a little more about me and what I do, feel free to check the 'About' page.
I just need to find a suitable ASP.NET host now, and I think I've found one - then I can get this uploaded and out there :)
Tags: misc
Go to the archive for full list of articles.