It does seem a bit over the top in terms of complexity.

I mean I originally was never sold on MVP because of the need to create 1+ interface for every page or form.

But this is another level.

You have to ask yourself if all this extra coding is worth the testability of the form?

Are you really getting the payback from all this extra complexity?

Can you say you have upped productivity?

Is the number of defects caught worth this?

Do you really use DataSets in a real world application with all this layering?

It is obviously very well thought out but  it really seems like the time to market is much increased and I know I would have to justify that to somebody.

Sorry to sound so critical but I am really looking to be proved wrong.

Can you provide video for download?

Thx.

Thanks for the answer and after re-reading my post, it could have been worded more constructively.

I use TDD myself along with CI and I am sold on the idea.

I also use ASP,NET MVC, NHIbernate, Castle IOC, Validation, JQuery and Rhino.

Maninly to give me better productivity and maintainability.

The bottom line being I write less code and not more.

As the guy said, there are 6 objects involved in a typical MVP piece.

That just adds to maintenance and coupling.

The architecture to me would seem to heavily influinced in the need to be testable than true cohesion.

I take the opinion of not testing my Views in MVC.  The extra effort required does not seem worth the need to test what really is not testable.

In the same way as now I am woring on a windows service, I am not even attempting to test that code.

All the code that has the main functionality is in a different library.

My problem with MVP that the presenter gets caught up in presentation detail which in my opinion it should not.

MVP was created to solve hardware problems while developing SmallTalk.  It has been overplayed in the real world.

Microsoft first sold ASP.NET (if anyone can remember to 2002) as the perfect MVP implementation because of the code behind model.  The HTML was your view, the .NET framework was your controller (it handled the events, page redirects, etc) and the code behind was your model (or pointed to your model...i.e. the BLL).

Now a short 6-years later Microsoft says ASP.NET is not MVC and not ASP.MVC is the hot topic for MVP.  History repeats itself.

I wish that people would stop worrying about 'what pattern should I use?', 'what Agile manifesto author should I idolize?', 'I need to spend 90% of my time make the 10% of my GUI testable'...and worry about writing good software by FIRST AND FOREMOST GETTING GOOD REQUIREMENTS.    OVER THE PAST 30 YEARS THE AMOUNT OF BUGS ATTRIBUTED TO REQUIREMENTS HAS BEEN 50% HIGHER THAN ANYTHING ELSE AS A SOURCE OF BUGS (IBM web site has a WONDERFUL article on this if anyone cares to Google for it.

SECOND - sit down as a TEAM and discuss how to implement the REQUIREMENTS using several CANDATE ARCHITECTURES.  This means DO NOT PULL OUT A TOOL WRITE AN ERD AND WRITE OBJECTS THAT MAP TO IT.  This means DO NOT PULL OUT A CODE GENERATOR TO START STUBBING OUT CLASSES.  This means looking at your USE CASES and writing out some data flow, activity diagrams, whatever, and getting the design write on paper.  That way should you choose to use PHP, PYTHON, RUBY, JAVA, .NET, WHATEVER, the design WILL WORK.

NOW, all you cowboys out there can start stubbing out some candiate objects and writing some tests for that.

EVERY DEVELOPER SHOULD READ IN ORDER:

The Inmates are Running the Asylum

The Pragmatic Programmer

Pragmatic Unit Testing

Martin Fowlers - code smell 'SPECULATIVE GENERALITIES' - can't believe how many of you worship him yet haven't read about that code smell!

Using a Pattern does not a good program make - in fact more often than not I've seen it make a program overly complex and have a sky high maintenance around it.  And like any scam artist, those who will respond to this will say it's the person who implemented it's fault, not the patterns - oh no it can never be the pattern.  

Well yes it can...they're called anti-patterns, and this occurs when people try to fit square pegs in round holes and 90% of time when someone is searching through the books and the internet for a pattern to use as if they're recipes, then the project is going to be bloated and become a maintenance nightmare in my experience...and I have spent the last several years cleaning up other peoples work, so I know a little bit about it.

If you GATHER GOOD REQUIREMENTS, DESIGN BEFORE YOU EVEN THINK ABOUT A TECHNOLOGY OR DATABASE, WORK WITHOUT A DESIGN PATTERN BOOK/WEBSITE you will grow in YOUR knowledge, and YOUR experience and find that your code will fall into patterns all on its own when ITS REQUIRED.

>> I'm not sure how cohesion factors into the mix. Would you elaborate?

I mean by the fact that the presenter has deep knowledge or need to  know kowledge about the view.  

Even if this is abstracted by a callback layer.

I think that again the callback mechanism has been crated for testability.

Testability is great but it should not influence architecture to this degree.

The presenter should not be hung up on UI concerns.

It should just provide and process data .

I think people have got caught up on the whole code coverage thing.

A recent thread on the ALT.NET group was from one guy complaining about his devs having hacks to get round 100% code coverage.

This is a sad statement.

Do we really get such a return from designing our systems to be totally covered by unit tests?

Unit tests to me are specification.

I do get better feed back from integration tests.

I get the best feedback from a user actually using the system.

The sooner they can do that the better.

If I am going to try and second guess every bug that might appear by trying to cover every code path then I am writing code that is of little worth.

Why stop there, why not have a test that throws every exception in the framework.

Pingback from  Dew Drop - July 17, 2008 | Alvin Ashcraft's Morning Dew

@Dave

Your right.  I was in a pissy mood and shouldn't of been so pissy here.  I appologize.

My mood is a result from spending a lot of time lately recovering the titanic because someone thought more was better and seemed to put Enterprise Patterns in a shotgun and shot it at the code base I inherited.

Couple that with being surrounded by developers, who get giddy and scream like little girls watching whatever boy band is popular today, when someone mentions the name Fowler or Manifesto.

Again...sorry man - I was totally out of line.  It was one of those days.

Is there going to be a link to the source code?

@Dave

My apologies.  The source code is available at the bottom of Rik's blog post entitled "Tech Valley Code Camp".