Rob Conery posted about why he thinks it’s important to learn MVC and I agree that it is important to learn MVC and his points are all valid. The point that’s missing though is this: So you can have an informed opinion on what the benefits are of MVC vs insert all other web technologies here.
Within MVC itself there are some interesting questions to answer like what MVC framework to use. There’s actually more than just the ASP.NET MVC framework, and even if you settle on ASP.NET MVC, you’d be wise to also evaluate the different viewengines, the different controller conventions and the various routing styles.
If you get asked your opinion on whether MVC is going to be more suitable than WebForms for a new project you’re starting, there’s only one way you can truly answer that question with any authority and it’s from having a good understanding of what MVC offers. The best way to get that understanding is to learn it.
This holds true for pretty much any comparison. Is the Entity Framework more suitable than NHibernate? Is MSSQL server more suitable than Oracle? Are Macs more suitable than PC’s?
You can read as many articles as you want to get a general feel for what each has to offer, but the only way you’re going to get a truly valuable opinion is to roll up your sleeves and get dirty with the tools.
Even just building the most basic applications will tell you what the friction points are, what the benefits are, how this technology will require you to approach the problem and ultimately form your own opinion.
I agree with Rob, you should learn MVC, but I’m adding another reason to the list.
I’ve resisted the urge of learning a dynamic language like F# or Ruby for a while but it’s hard to ignore that the deeper you go into c# the more it gets in your way. In the last 2 days I’ve had 2 problems in c# that simply wouldn’t have existed in a dynamic language.
First problem I had was needing to assign multiple values to an object property but I wouldn’t know the type of the value until runtime. The property was an int, but I could potentially assign a decimal or a long depending on what was returned from the underlying data source. Because c# requires static typing I had no choice but to choose an int as the property type and then do a bunch of crazy casting to handle the various runtime issues. In a dynamic language, I’d just assign the values and the type would be inferred.
The second problem I had involved variance with generic collections. The situation was that I had an interface called IParcel which was implemented by two classes, Disposal and Parcel. I also had a function that accepted as a parameter IList<IParcel>. The problem was that I couldn’t pass an IList<Disposal> or IList<Parcel> to the function even tho Disposal and Parcel derive from IParcel and therefore should be considered perfectly valid. Instead I had to call ConvertAll() on the collections to convert them to IList<IParcel> objects and then pass the converted list to the parameter. In a dynamic language, I would just pass either list into the collection and life would go on.
Variance is being addressed in c# 4.0 but it’s only one circumstance where these sorts of problems begin to hit the limit of what c# can do.
It will be interesting to see what direction Microsoft takes with C# and dynamic languages. It seems that they’re looking to accommodate dynamic typing within C# as much as possible but where pure functional programming is required they’re pushing people to F#. This makes good sense but I wonder if the lines will become blurred by allowing easier access to F# from directly within C#.
Whatever they do, I don’t think I’ll be making a full blown switch to a functional language soon but I’ll be watching what happens in this space as there is definitely room for some interesting solutions to these interesting problems.
Well it seems Iron Speed are at it again with their ridiculous licensing policies. I received an email from Iron Speed which contained the following information:
Beginning with our upcoming Version 6.1, Iron Speed Designer can be installed only on one machine at a time. Simply uninstall Designer to move to a different machine. As with earlier releases, your software license permits one named user to run on one machine.
For years, power users have purchased extra licenses so they can run on multiple machines. If you’d like to use the product this way, we are pleased to offer a special one-time 30% discount on additional licenses for yourself or other currently licensed developers on your team. Please contact your sales representative to assist you with a purchase or email sales@ironspeed.com.
This offer expires on April 23, 2009 and will not be repeated.
There are 2 things that annoy me with this “incredible offer”. First is that they’re actually making it harder for you to run multiple instances of the designer. From what I’m reading, you can no longer activate and deactivate instances, you actually need to uninstall your copy of Iron Speed to transfer it between machines.
Second, they are giving you the opportunity to buy more licenses so you can run the software you already own on more than one machine. It’s completely absurd. If you do any sort of consulting work, there’s no doubt you’ll have multiple machines. I personally have 2 laptops and a desktop. At any given time, depending on the job I’m doing, I could be on any one of the three computers. It’s just not viable to have 3 licenses of a single product to use on those machines. Throw in the fact that I can’t even run Iron Speed from within a virtual machine and you suddenly question whether Iron Speed have any idea what they’re doing when it comes to licensing and marketing.
Iron Speed have a decent product, but the ridiculous nature of their licensing continues to annoy me so much that I will refuse to purchase from them.
There’s a bit of buzz around Domain Driven Design at the moment and while I haven’t gone too deep with DDD, there are certainly some aspects which have challenged the way I’ve been approaching problems.
In the past I’ve used plenty of ORM tools which are heavily dependent on the database and this reliance often results in a domain model that directly represents the database table schema. This is often a quick and convenient method of creating a data layer and it works well for the most basic of CRUD applications, however when your applications begin to get complex, this method can be left sorely wanting.
What has interested me most about DDD is the concept of a Doman Context and modeling "objects" based around a specific context. In a recent project this has worked for me in two ways.
First I had a domain context that was based around reporting, where I had data coming from a number of different tables but had to be mapped to a single object. The situation was analogous to having a business that could accept orders online, in store or by mail and each different order was stored in a separate table. I then wanted to create a sales report that showed a summary of all sales in a common format. With ORM solutions I’ve used in the past, I would have 3 objects mapped to my different tables called OnlineOrder, MailOrder and StoreOrder. I would then have had to massage that data into a common ReportOrder object and bind it to my report.
With NHibernate I was able to create a mapping for each table and map them all to the single ReportOrder object. This allowed me to have a nice clear representation of my domain model that was clearly abstracted away from my database model.
The second situation I had was where I had a single table that I needed to be represented in multiple domain contexts. For example I had a Customers table which had one-to-many relationship with an Addresses table and an Orders table. In one context I wanted to update the Addresses and in another context I wanted to validate orders. If I was using an old school ORM, I’d have a Customer object with a collection of Addresses AND a collection of Orders. I’d have to make a choice as to whether or not I wanted to lazy or eager load each collection based on what I was doing with the parent object. With NHibernate I was able to just create two seperate objects that did exactly what was required by domain context. One Customer object had a child collection of addresses whilst a seperate one had a child collection of Orders. This example is greatly simplified but being able to create multiple objects based on specific contexts has meant I’ve been able to greatly simplify my domain model and reduce the complexity of my objects.
I haven’t done enough DDD to consider myself an expert or not, but combined with NHibernate I’ve definitely been given plenty to think about when it comes to modeling my domains.
