Comments on: Coding: An abstract class/ASP.NET MVC dilemma

By: DotNetShoutout

DotNetShoutout — Wed, 16 Sep 2009 22:45:35 +0000

Coding: An abstract class/ASP.NET MVC dilemma – Mark Needham…

Thank you for submitting this cool story – Trackback from DotNetShoutout…

By: ASP.NET MVC Archived Blog Posts, Page 1

ASP.NET MVC Archived Blog Posts, Page 1 — Wed, 16 Sep 2009 05:44:33 +0000

[...] to VoteCoding: An abstract class/ASP.NET MVC dilemma (9/12/2009)Saturday, September 12, 2009 from http://www.markhneedham.comI previously described a refactoring that we [...]

By: DotNetBurner - ASP.net MVC

DotNetBurner - ASP.net MVC — Tue, 15 Sep 2009 02:08:49 +0000

Coding: An abstract class/ASP.NET MVC dilemma…

DotNetBurner – burning hot .net content…

By: Daily tech links for .net and related technologies - September 13-15, 2009 - Sanjeev Agarwal

Mon, 14 Sep 2009 06:03:03 +0000

[...] Development Exploring ASP.NET 4.0—Web Forms and Beyond Coding: An abstract class/ASP.NET MVC dilemma Functional Construction for ASP.NET Web Forms Inheriting Themes for SharePoint publishing sites [...]

By: Tweets that mention Coding: An abstract class/ASP.NET MVC dilemma at Mark Needham -- Topsy.com

Sun, 13 Sep 2009 21:21:19 +0000

[...] This post was mentioned on Twitter by planettw. planettw said: Mark Needham: Coding: An abstract class/ASP.NET MVC dilemma: I previously described a refactoring that we have b.. http://bit.ly/9mJKi [...]

By: Jeremy Gray

Jeremy Gray — Sun, 13 Sep 2009 15:36:27 +0000

If you introduce NewParentModel as the new base class there is an extra step that has to be taken, that being to update ParentPage to reference NewParentModel instead of ParentModel.

If you instead take the other approach I mentioned and add a new derivation from ParentModel, change BusinessProcessModel1 and 2 to refine it, and then add the new property to the new class, ParentPage (and other references to ParentModel) wouldn’t have to change.

Both approaches work but have their pros and cons. For your scenario, the latter approach may be a better fit.

So, just to be clear on how the latter approach would look:

ParentModel
Property2

SubParentModel : ParentModel
Property1

BP1Model : SubParentModel

BP2Model : SubParentModel

BP3Model : ParentModel

By: TDD: Testing sub classes at Mark Needham

TDD: Testing sub classes at Mark Needham — Sun, 13 Sep 2009 12:22:47 +0000

[...] ran into another interesting testing dilemma while refactoring the view model code which I described in an earlier post to the point where we have an a… which means that we now have 3 classes which did the same thing 80% of the [...]

By: Mark Needham

Mark Needham — Sat, 12 Sep 2009 22:30:15 +0000

I’m probably not quite understanding something but how would that approach work for BusinessProcessModel3 on the ParentPage?

On the ParentPage say we make use of Property1 and Property2 and Property2 is the one which only exists for BusinessProcessModel1 and BusinessProcessModel2.

So we’d have something like this:

NewParentModel
Property1

ParentModel : NewParentModel
Property2

BP1Model : ParentModel

BP2Model : ParentModel

BP3Model : NewParentModel

I guess we would need to change the type for the ParentPage to be ‘NewParentModel’ so that we have a common class for ParentPage. If we have the type for ParentPage as ‘ParentModel’ then I think we’d get a class cast exception when we’re in BP3 since you can’t downcast BP3Model to ‘ParentModel’?

Maybe there’s a simpler way and I’ve misunderstood…

By: Jeremy Gray

Jeremy Gray — Sat, 12 Sep 2009 17:44:44 +0000

I could be missing something in relation to your requirements but it looks like you just discovered that ParentModel itself needs a base class from which BusinessProcessModel3 will need to derive, leaving BusinessProcessModel1 and BusinessProcessModel2 deriving from what is currently called ParentModel. Alternatively, you could mentally visualize this as adding a new class between ParentModel and BusinessProcessModel1 and 2, with the new property added to the newly-created class.

All in all, this is pretty standard object model evolution, right up until you encounter the diamond problem, at which point you can either do what you’ve done so far (put the property on a base class even though not all derived classes need it) or go for something a bit more esoteric.