Month: March 2008

Agile Joe (Joe Ocampo) has a good post on the ‘Open Closed Principle’:

“The open closed principle is one of the oldest principles of Object Oriented Design. I wonâ€™t bore you with the history since you can find countless articles out on the net. But if you want a really comprehensive read please checkout Robert Martinâ€™s excellent write up on the subject.

The open closed principle can be summoned up in the following statement.

open/closed principle states “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”;[1] that is, such an entity can allow its behavior to be modified without altering its source code.

Sounds easy enough but many developers seem to miss the mark on actually implementing this simple extensible approach. I donâ€™t think it is a matter of skill set as much as I feel that they have never been taught how to approach applying OCP to class design.”

I have created a new ‘MS MVC User Control’ and the data will be sent to this ‘control’ and rendered inside the ‘showResults’ div (see javascript above), as well as a structure to pass the data with (I prefer this route):

I took some steps to see how well MS MVC would coexist with Webforms on a hosted environment. One of the things I really like about the new MS MVC is the ability to be run inside the same project/web application as webforms. This will allow for a migration plan vs. just a complete total rewrite.

The first step was to add in the 3 assemblies required. The assemblies in preview 2 were separated from the System.Web.Extensions, these assemblies are:

System.Web.Mvc (dependent on Routing)System.Web.Routing (dependent on Abstractions) <— note: this can be used outside of MS MVCSystem.Web.Abstractions

see the note above: when adding routes with IIS6 and II7 classic mode, you must include the .mvc (or any unique extension). This is important. Your host will also need to map .mvc to the ISAPI .net. Although, as I hope to show, you can actually just use routing to get around this.

Basically, the routing will let you intercept any call to a page and route it to a controller and action! So in the above example for ‘ViewMissionSummary’, I took an existing page in Webforms and created a new controller, action and view.

To help with binding to the view I created a new ‘MissionSummaryViewData’ struct. As you see above, the RenderView takes the name of the view and an object ‘viewData’. The viewData is a way to attach a specific data structure type to a view

I don’t have to do this, I can just pass key pair values, ie. ViewData[“MissionSummaryView”] = missionSummaryViewData and call ‘RenderView’. However, making it typed allows me to use intellisense and have type checks in my view!

ie.

Missions Flown: <%= ViewData.MisSummary.Count.ToString()%>

ViewData is a struct defined above that has a List<MissionSummary> , which has a ‘count’ – this is very nice feature of MS MVC! You might have noticed above that I still have ‘databinding’ going on in MS MVC. My solution uses Repeaters which are ‘MS MVC friendly’ and I was able to bind my list to the repeater.

Routing

Now that we have this in place, lets talk about how the routing will work. Just deploying the current code above, I can access my new code via the following url:

In my code though, this ViewMissionSummary still has a ViewMissionSummary.aspx webform page. I want to replace it with the above MVC code. Instead of changing all my links in my solution to point to this new url (which isn’t very friendly!) I create a new route:

Ayende has a post that exemplifies principles that I see as extremely important to a good development environment.

Some key points:

Infrastructure Ignorance – If I have to deal with my infrastructure explicitly, then I need to have developers dealing with it on a regular basis. That doesn’t mesh well with the idea of moving all the complexity to the infrastructure.

Fizz Buzz concepts – the code that a developer should write should be simple and easy to follow.

Follow good design principals – the code written should naturally lean toward single responsibility principal, separation of concerns, etc

Easy to figure out – It should be simpler than the alternative for any non trivial scenario. Ideally, you can explain how to solve most scenarios using this approach in half an hour or less (ignoring the infrastructure part, which may be very complex).

No training wheels – one of the things that drives me crazy is having two ways to do things. One for the average developer, the second for the architect. This usually comes out of putting training wheels on the first approach that make it hard to deal with in more advance scenarios. I see this as a sign of contempt for the rest of the members of the team. If you expect the rest of the team to work in a certain way, make damn sure that this is a way that this is a way that you can live with.

“The code that a developer should write should be simple and easy to follow”

There is so much about this that needs to be expounded upon. I really think the Single Responsibility Principle(SRP) is vital to this concept. I’ve seen some pretty ugly looking code all over the place where I’m at right now. Very large functions that are procedural in nature. I’d personally rather have many classes than classes stuffed with tons of code. Also, too much code in asp.net code behind pages is a major ‘no-no’. For myself, I’ve had to do much refactoring to get code back into business/presenter classes and out of the code behind. (This is one reason I like the Monorail/MS MVC approach). I could go on and on about this one.

“Easy to figure out”

Whew, amen here. Here is my code smell for this one: When you have no code in the business layer and all it is a pass through. Why do I say this ? Typically this means all the logic is in the UI or in the data layer. This is why I’m a big fan of a domain driven design with clean POCO business objects. Separation of Concerns is important here. I know it’s always debatable in the MS developer world, but when I see datasets I cringe. I think datasets tend to make developers think just in terms of the data layer. They are confusing to see the domain picture. So for me ‘Easy to figure out’ == well defined domain model.

I should add, I think creating a rules engine (IRules) and/or validation objects that can be kept away from the actual entity objects is important. This allows me to see the domain without clutter of all the rules (ie. different sets of business rules for a each client – the entity would hold a collection of ‘IRule’ objects associated to it’s particular instance)

The struggle is working in environments where principles aren’t openly discussed. I think ‘best practices’ should be complemented with developers all speaking a common language of good OO principles. On some teams I really enjoyed working with, stressing these principles made us a successful team, it was a very growing experience to me as a developer.

Ayende has a post that exemplifies principles that I see as extremely important to a good development environment.

Some key points:

Infrastructure Ignorance – If I have to deal with my infrastructure explicitly, then I need to have developers dealing with it on a regular basis. That doesn’t mesh well with the idea of moving all the complexity to the infrastructure.

Fizz Buzz concepts – the code that a developer should write should be simple and easy to follow.

Follow good design principals – the code written should naturally lean toward single responsibility principal, separation of concerns, etc

Easy to figure out – It should be simpler than the alternative for any non trivial scenario. Ideally, you can explain how to solve most scenarios using this approach in half an hour or less (ignoring the infrastructure part, which may be very complex).

No training wheels – one of the things that drives me crazy is having two ways to do things. One for the average developer, the second for the architect. This usually comes out of putting training wheels on the first approach that make it hard to deal with in more advance scenarios. I see this as a sign of contempt for the rest of the members of the team. If you expect the rest of the team to work in a certain way, make damn sure that this is a way that this is a way that you can live with.

“The code that a developer should write should be simple and easy to follow”

There is so much about this that needs to be expounded upon. I really think the Single Responsibility Principle(SRP) is vital to this concept. I’ve seen some pretty ugly looking code all over the place where I’m at right now. Very large functions that are procedural in nature. I’d personally rather have many classes than classes stuffed with tons of code. Also, too much code in asp.net code behind pages is a major ‘no-no’. For myself, I’ve had to do much refactoring to get code back into business/presenter classes and out of the code behind. (This is one reason I like the Monorail/MS MVC approach). I could go on and on about this one.

“Easy to figure out”

Whew, amen here. Here is my code smell for this one: When you have no code in the business layer and all it is a pass through. Why do I say this ? Typically this means all the logic is in the UI or in the data layer. This is why I’m a big fan of a domain driven design with clean POCO business objects. Separation of Concerns is important here. I know it’s always debatable in the MS developer world, but when I see datasets I cringe. I think datasets tend to make developers think just in terms of the data layer. They are confusing to see the domain picture. So for me ‘Easy to figure out’ == well defined domain model.

I should add, I think creating a rules engine (IRules) and/or validation objects that can be kept away from the actual entity objects is important. This allows me to see the domain without clutter of all the rules (ie. different sets of business rules for a each client – the entity would hold a collection of ‘IRule’ objects associated to it’s particular instance)

The struggle is working in environments where principles aren’t openly discussed. I think ‘best practices’ should be complemented with developers all speaking a common language of good OO principles. On some teams I really enjoyed working with, stressing these principles made us a successful team, it was a very growing experience to me as a developer.