.NET and the elusive MVC pattern

November 18th, 2008

A couple weeks ago, I went to a Microsoft “Heroes Happen {Here}” event.  (Good process should mean that there is no need for heroes, but that is a topic for another blog!).  Anyway, part of the development track was an introduction to MVC for .Net.  MVC has been around the J2EE world for so long, its passe.  However, there has never really been a good implementation of it in the .NET world.

MVC or Model-View-Controller is a design pattern that is used by architects to enforce an enterprise capable design.  The advantage is that the GUI is very light weight – since it is only concerned with displaying data passed to it (the VIew in MVC) and the Model handles all the underlying business/persistance with the all powerful controller being a lightweight bridge between the two.  It scales well, is easily extensible and extremely consistant from one section of code to another – making easy to maintain.

When I started my last project, I looked for a .NET MVC example.  I found a couple articles on the web and 2 books that had dedicated space to it, but none of these examples really seemed to capture the power of MVC.  In fact a couple completely missed the point altogether.

I decided that many people treat the code behind page in .NET as a mini-controller, so maybe it really didn’t make sense to try to apply the MVC pattern in .NET.  There were other ideas floating around.  Martin Fowler’s MVP pattern was a good, but somewhat complex alternative. In the end, I spun my own architecture.

When I heard that Microsoft was coming out with an example of the MVC pattern, I was skeptical.  I, personally, had decided that the MVC pattern didn’t fit within the .NET framework well.  The example they showed at the Heroes event was well thought out.  It’s not 100% ready for prime time, but its close.

What do I mean?  Well, setting up a project for MVC is simple. You choose the MVC project type and Visual Studio works its magic.  As long as you keep your naming conventions and directories straight and don’t put anything into the code behind, it all works great.  However, there is nothing to enforce any of this.  You are relying on developers behaving well.  They will, in the beginning of a project.  By the end of a project, they are more worried about meeting deadlines than following the architecture.  Microsoft said that there next version of MVC may not have any code behind pages.  That will feel a little stange to the hard core .NET developers, but it will make life much easier for the Architect and Team Lead.

A Little Too Incremental – Part Duex

November 30th, 2007

I was having Thanksgiving dinner with my sister.   My sister comments that she read my A little too incremental blog and thought it was pretty funny.  (I guess that is why I was still invited to Thanksgiving dinner).  She didn’t think it was accurate, though.

So, the conversation went as follows:

Her:  I read your blog the other day.

Me: Was it okay?

Her:  Well, it didn’t put me in the best light, but it was pretty funny!

Me:  Well, if it makes you feel any better, more then 1 person asked me if you wanted a job.

Her: Really?  It’s a shame I don’t live closer.  I did have 1 problem with the blog?

Me:  Problem? oh.  What was that?

Her:  It wasn’t very accurate.

Me:  Well, you know, it may not have been word for word, but I tried to get the gist of the conversation right.

Her:  No, you don’t understand.  It’s far worse then you portrayed.

Me:  What?

Her:  Really. I’m on the data modeling team.  We used to be part of the various development teams, but they kicked us off.

Me:  Huh?

Her:  They kicked the data modelers off of the teams.  Apparently we ask too many questions to be agile.

Me:  Too many questions?  What kind of questions?

Her:  You know.  Things like, “What type of data are you capturing for that object?”,  “What is the max length of that string?”, “Aren’t an employee, customer, client, and user all variations of a ‘person’.  Shouldn’t we be capturing a subset of the same data for each so that we can have some code re-use and give the data warehouse folks common data to search on?”.

Me:  Troublemaker!

Her:  So, now we aren’t allowed on the development teams.  We have to wait until they make changes to their copies of the database, then bring them back and reverse engineer the changes to figure out what they did.  Once we figure that out, we can start working on the business intelligence tasks.

Me:  So, let me get this straight, you need to reverse engineer the database to figure what is being done.  Since each team is doing this on their own, you could get conflicting changes, and…

Her: Oh, we have conflicting changes all the time.  We give them to our boss and he calls the lead for the affected development teams to get resolution.

Me:  Well, at least that sounds like it functions well.

Her: Actually, that is why we are on iteration 4 while they are on iteration 34.

A Little Too Incremental

November 19th, 2007

I was talking with my sister last night.  The usual stuff, “How’s the family, how’s work…”

As it turns out she is looking for a job.  I asked why.  She stated that her company (which develops COTS and then offers services to customize) was up against a wall.  They had been promising a product (I think she said “for years”) and had a deliverable due in December.  She said that there was no chance of hitting that deadline.

We had a conversation similar to the following:

Me: (Knowing they adopted RUP about 1.5 years ago) That’s rough.  Where are you in the process?

Her: Oh, I’m following my process!

Me: (thinking “My process? hmmm…”) No, what phase are you in?

Her: Phase?  No, I use ClearCase when I need to and ClearQuest when I need to.  I’ve got that down.

Me: (Starting to understand why the project is having issues)  So, you’re not following an iterative process?

Her: Sure we are — we iterate all over the place.  My team is in iteration 4, while the development team is on iteration 32.  We tend to be behind ’cause they keep making changes and we need to catch up.

Me:  Ok, so you are following an iterative process, but not necessarily RUP?

Her:  No, its RUP, well lately everything has been agile?

Me: (wondering if my sister has suddenly developed blonde roots) Agile?  Well, that is good.  Then at least you’ll have something to deliver in December.  It may not be everything, but there will be something.

Her: No, it’s a mess.  All we do is go to meetings every morning.

Me: Oh, scrum meetings? good for you!  What do you think of Scrum?

Her: It stinks!

Me: Ummm, ok?  But you have a daily scrum in the morning for 15 minutes – what did you do, what are you going to do,etc…

Her:  Yep, that’s the one.

Me: Great! So the team got together and decided what parts of the project can be delivered for this sprint, you’ve got 2 sprints by the end of December, sounds promising!

Her: Sprint?  The whole team never gets together to decide anything. My team just meets in the morning.

Me: Oh, so this is a big project?  You meet with your team and your scrum master then meets to have a scrum of scrums with the other leads.

Her: Its about 80 people.  I don’t think my boss has ever met with the other team leads – well, since maybe July.  He’s got a list of stuff to do and he tells us when to do it.  When things don’t work with what the other teams develop we have to go back and fix it.

Me: Alrightly then, let me know if you need help with your resume….

Can a SOA be created using Agile methods?

October 30th, 2007

A friend pointed out an interesting blog called RUP versus Agile for SOA Methodology by Eric Roch.  The initial premise seemed to be that Agile methodologies don’t provide enough structure to build a SOA.  My initial belief was that he misunderstood what was meant by agile methodologies.  He referenced extreme programming (XP) as his example of an agile methodology.  Granted, XP would not be my first choice for putting together a SOA either.  That really isn’t it’s purpose.  However, XP certainly can be used to create web services for the SOA.

He goes on to state that a lightweight version of RUP could be fabricated to provide design “deliverables”.  By deliverables, he means the structure and design used to enforce a set of standards across the SOA.  He does point out that, “RUP’s iterative nature and focus on architecture early in the process are well-suited for SOA.”  The key according to Mr. Roch is to keep the process lightweight and iterative.  What really struck me as fascinating is that is exactly the purpose behind OpenUP.  OpenUP is a lightweight version of RUP that is highly compatible with Agile development techniques.  Of course, OpenUP won’t really deal with the enterprise architecture requirements of the SOA either unless that is part of the architectural constraints of the various projects within the SOA.

Basically, Mr. Roch is treating a SOA as a single project rather then a series of projects build over a period of time by different groups who are experts only within the varying domains of the SOA.  An overarching architecture needs to be in place to define the domains and the governance processes and ensure that it meets its potential.  Otherwise, all the process in the world applied to individual projects will leave the business with nothing more then disjointed and conflicting web services.   The reality is, the problem he is trying to resolve has nothing to do with Agile vs non-Agile.  It is all about SOA architecture and governance.  Agile methodologies work well within that framework.  In fact, it is reasonable to assume that since one of the promises of SOA is the ability to respond quickly to changing business needs, that Agile methodologies are the perfect complement for a SOA.

Unfortunately, Mr. Roch is unfamiliar with the benefits of using a lightweight process framework like OpenUP to drive agile development.  I think if he was more aware of the benefits, he would see that using OpenUP and Agile development could be a win-win for the development teams creating the underlying services that make up the SOA and the architects trying to enforce the governance.

.NET and NHibernate

August 17th, 2007

Many Java programmers are familiar with ORM (Object Relational Mapping) tools and, in particular, Hibernate.  Hibernate allows a developer to map their relational database to their POJO (Plain Old Java Objects) and have Hibernate handle all the CRUD (Create, Read, Update and Delete) operations.

In the .NET world, ORM tools are much less common.  Many programmers follow a dataset focused approach to programming.  In earlier versions of ASP.NET, Microsoft offered data binding to many of its tools using datasets.  It just never occured to many programmers that there was a better approach.  So, when Hibernate was ported to .NET (as NHibernate), it was widely used by programmers that had used Hibernate, but it did not get the widespread acceptance that Hibernate received in the Java programming world.  With ASP.NET 2.0, Microsoft expanded its controls to allow binding to objects and collections of objects.  This created a greater demand for ORM tools.  Although still not as popular with .NET programmers as they are with Java programmers, ORM tools (and NHibernate in particular) are gaining market share.

In fact, Microsoft has been working towards building its own ORM capabilities (called LINQ) from directly within .NET applications without the need for a third party ORM tool.    However, its more focused around rewriting the syntax of queries and returning datasets that can, optionally contain objects, rather than removing the need to manually code CRUD operations.  I’ll write a separate blog about Microsoft’s LINQ product later on.

Whether Microsoft puts out a viable competitor to NHibernate has yet to be seen.  In the meantime, NHibernate offers some great functionality, is easy to use and saves programming time as programmers only need to define relationships in XML rather then write the CRUD code from scratch.

Interesting Links:

DoDAF and RUP — The Department of Redundancy Department?

July 30th, 2007

I’m currently the architect on a project that is heavily RUP (Rational Unified Process) centric.  As we are pushing through the government’s C&A (Certification and Accreditation) process, the government project manager “found out” that the project must comply with the DoDAF (Department of Defense Architecture Framework).  This was a little bit of a surprise since you would normally expect this type of requirement to pop up somewhere closer to Inception.  But, here we are, so the goal is to meet the requirement without having to recreate the architecture and design that has been developed under the Rational Unified Process.

DoDAF is a framework that is designed to handle almost anything that the Department of Defense may need to acquire/build.  It provides no methodology – just “views” of the enterprise.  These views are broken into 3 categories (Operational, Systems, Technical Standards) as well as the ominous sounding “All View”.  These “views” are, in fact, a series of documentation and diagrams used to provide insight onto the project from a particular perspective.

RUP is a process for building applications.  It can be seen as a set of best practices to help ensure that the project will meet the customer’s needs.  It includes its own set of documentation (UML) for accomplishing the same goals as DoDAF.  So, my initial reaction was that this was going to be a major exercise in being redundant.

The good news is that it is not turning out to be the case at all.  RUP employs UML to model the application.  DoDAF does not specify UML, but considers UML to be an acceptable method for completing many of the views.  So, much of the work is done.  Obviously, it would have been better to have employed the DoDAF with RUP from the beginning and keep everything in sync.  Given that the both use UML, it would be fairly straightforward to follow the RUP process while complying with DoDAF without much additional work.

Some interesting links on the topic:

http://www.ibm.com/developerworks/rational/library/mar06/widney/index.html

ftp://ftp.software.ibm.com/software/rational/web/whitepapers/G507-1903-00_v5_LoRes.pdf.