According to Sun and Msdn it is a design pattern.
According to Wikipedia it is an architectural pattern
In comparison to design patterns, architectural patterns are larger in scale.
(Wikipedia - Architectural pattern)
Or it is an architectural pattern that also has a design pattern ?
Which one is true ?
MVC is more of an architectural pattern, but not for complete application. MVC mostly relates to the UI / interaction layer of an application. You're still going to need business logic layer, maybe some service layer and data access layer. That is, if you're into n-tier approach.
Why does one of them have to be true?
Both can be true, depending on point of view.
MVC can be an architectual pattern, if it forms the basis of the application architecture.
It can also be seen as simply a design pattern, an abstract notion that is applicable to any application.
Design patterns say how to write code effectively (considering Code Metrics).
A few benefits:
Easily Maintainable
High Re-usability
Readable because of abstractions
Architectural patterns say how to utilize resources effectively.
Parallel tasks execution like programmers and graphic designers can work parallel.
Multiple technologies can be utilized to build a software.
In MVC,
a). Views can be created using javascript templates and also html can be used
b). Controllers can be written .NET framework and
c). Models can be written in Java - a java service may be used that returns only json data.
While in design pattern, a pattern can't be implemented in which
code can be written in multiple technologies like AdminUser class in Java,
Customer class in C#, Partners class in Php and a factory pattern in Ruby
:); hmmm..so easy?:)
I know that it's been answered awhile ago, but no one has yet mentioned the book that made MVC famous: Pattern-Oriented Software Architecture (POSA), by Buschmann, et al published in 1996. Though not as widely read as the Design Patterns book, by Gamma, et al, POSA is one of the foundational books used by the patterns community.
Oh, and POSA very clearly identifies MVC as an architectural pattern. My hunch is that MS and Sun are just being sloppy and calling every pattern a "design pattern".
The design patterns inside the Model/View/Controller (MVC) triad of classes include and may not be limited to:
Observer, decoupling objects so that changes to one (the model) can affect any number of others (the views) without requiring the changed object (the model) to know details of the others (the views).
Composite, which lets us treat a group object (a composite view) just like we treat one of its individual objects (view components).
Strategy, where a view uses an instance of a Controller subclass to implement a particular response strategy; to implement a different strategy, simply replace the instance with a different kind of controller.
Factory Method, specifying the default controller class for a view.
Decorator, adding scrolling to a view.
Reference
Pages 4 to 6 (Section 1.2 Design Patterns in Smalltalk MVC)
Pages 293 to 304 (Observer design pattern)
Pages 163 to 174 (Composite design pattern)
Pages 315 to 324 (Strategy design pattern)
Pages 107 to 116 (Factory Method design pattern)
Pages 175 to 185 (Decorator design pattern)
Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1994.
I think both are true. If you're looking at a particular instantiation of MVC in a framework like Ruby on Rails, that instantiation is more of a design pattern. If you look at MVC as a general concept, it's more of an architectural pattern.
If you put ten software architects into a room and have them discuss what the Model-View-Controller pattern is, you will end up with twelve different opinions. … Some of the purists out there will inevitably have qualms with what I refer to as “MVC”. Feel free to leave a flaming comment on the message board at the bottom of this Web page. I will gladly entertain different perspectives on what MVC means, but keep in mind that I do not care.
Josh Smith
MVC always mentioned and introduced as/in presentation layer in software architecture books.
Read these books:
Architecting Microsoft.NET Solutions for the Enterprise (Microsoft press)
Professional ASP.NET design patterns (Wrox)
Enterpise Solutions Patterns Using Microsoft.NET (Microsoft press)
Patterns of Enterprise Application Architecture (Addison Wesley)
A Practical Guide to Enterprise Architecture (Prentice Hall)
And according to Martin Fowler they are GUI architectures: Martin Fowler-GUI architectures
It depends on the size of the application, as it only affects GUI related classes, in a small one (mostly GUI) it could be considered an architectural pattern whereas in a huge one it would just be a design pattern that you apply to the GUI code (could be 10% of the apps code).
MVC is architecture pattern. Very clearly stated and shown at http://molecularsciences.org/zend/mvc_model_view_controller
Related
I used to have a nice set of coding standards I could print for coldfusion that was almost a framework but much looser with some code examples. Like teh use of createObject, more cfscript, error and message integration, Application.cfc usage and examples. Also seperation of buisness (actions) and display using cfincludes to make an index.cfm page 'a generator' of many actions leveraginf cfswitch/cfcase...etc. I am looking for some doucmentation or anything that I can print our and sit on my desk and refer to so my coding stays clean. Any help from the community would be very much appreciated.
Although rather dated, You may find what you are looking for among the many posts listed under the "Coding Guidelines" section on the "Articles" page of the MDCFUG - Mayryland ColdFusion User's Group website.
Here are some other options:
Univ. of Maryland ColdFusion Programming Standards
Sample Applications Methodology Guidelines provided by Adobe.com
SBA ColdFusion Programming Standards contains 126 pages of coding standard written for the U.S. Small Business Administration to insure security, promote code re-use, easy readability, and easy maintenance.
Oregon Health & Science University - Coding Guidelines which contains a number of GOOD versus BAD coding examples.
I'm unaware of any "official" Coldfusion specific coding standards. Where I work we collectively came up with our own based on many years of experience working with the language. A simple one for example is to use camel case. From what I've seen camelCase is preferred over snake case in Coldfusion, so as a rule we have:
In general, for files use lowerCamelCase starting with a lower-case letter, except for CFCs which should start with an upper-case letter as they represent a class in ColdFusion.
We have other standards broken up under headings such as:
Variable Naming
Operators
Scopes
Functions
ColdFusion Native
Functions
Indentation
......
I am looking for some doucmentation or anything that I can print our
and sit on my desk and refer to so my coding stays clean.
In addition to this I recommend you create a set of generic code snippets, such as you can use in Eclipse, that conform to any standard you decide to go with. These can then be easily distributed among team members, helping to keep things consistent as well as saving typing time.
I realise this is quite an old post now, but thought it would be worth mentioning http://wiki.coldbox.org/wiki/DevelopmentBestPractices.cfm. I think this is a good set of standards for writing CFML.
I am just getting into the concept of BDD and have listened to Scott Bellware's talk with the Herding Code guys. I have been playing around with SpecFlow some and like it pretty well.
I understand the distinction between ATDD and TDD as described in the blog post Classifying BDD Tools (Unit-Test-Driven vs. Acceptance Test Driven) and a bit of BDD history, but that leads me to a question.
As described, isn't using a BDD tool (such as MSpec) just another unit testing framework? It seems to me that it is.
Furthermore, this seems to suggest that using SpecFlow to spec out the lower level components (such as your repositories and services) would be wrong. If I can use the same tool for both ATDD and TDD of lower level components, why shouldn't I? There seems to still be some blurry lines here that I feel like I'm not quite understanding.
The Quick Answer
One very important point to bring up is that there are two flavors of Behavior Driven Development. The two flavors are xBehave and xSpec.
xBehave BDD: SpecFlow
SpecFlow (very similar to cucumber from the Ruby stack) is excellent in facilitating xBehave BDD tests as Acceptance Criteria. It does not however provide a good way to write behavioral tests on a unit level. There are a few other xBehave testing frameworks, but SpecFlow has gotten a lot of traction.
xSpec BDD: NSpec
For behavior driven development on a unit level, I would recommend NSpec (inspired directly by RSpec for Ruby). You can accomplish BDD on a unit level by simply using NUnit or MSTest...but they kinda fall short (it's really hard to build up contexts incrementally). MSpec is also an option, there has been a lot of work put into it, but there are just somethings that are just simpilier in NSpec (you can build up context incrementally in MSpec, but it requires inheritance which can become complex).
The Long Answer
The two flavors of BDD primarily exist because of the orthogonal benefits they provide.
Pros and Cons of xBehave (GWT Syntax)
Pros
helps facilitate a conversations with the business through a common dialect called (eg. Given ...., And Given ...., When ......, And When ..... , Then ...., And Then)
the common dialect can then be mapped to executable code which proves to the business that you actually finished what you said you'd finish
the dialect is constricting, so the business has to disambiguate requirements and make it fit into the sentences.
Cons
While the xBehave approach is good for driving high level Acceptance Criteria, the cycles needed to map English to executable code via attributes makes it infeasible for driving out a domain at the unit level.
Mapping the common dialect to tests is PAINFUL (ramp up on your regex). Each sentence the business creates must be mapped to an executable method via attributes.
The common dialect must be tightly controlled so that managing the mapping doesn't get out of hand. Any time you change a sentence, you have to find method that directly relates to that sentence and fix the regex matching.
Pros and Cons of xSpec (Context/Specification)
Pros
Allows the developer to build up context incrementally. A context can be set up for a test and some assertions can be performed against that context. You can then specify more context (building upon the context that already exists) and then specify more tests.
No constricting language. Developers can be more expressive about how a certain part of a system behaves.
No mapping needed between English and a common dialect (because there isn't one).
Cons
Not as approachable by the business. Let's face it, the business don't like to disambiguate what they want. If we gave them a context based approach to BDD then the sentence would just read "Just make it work".
Everything is in the code. The context documentation is intertwined within the code (that's why we don't have to worry about mapping english to code)
Not as readable given a less restrictive verbiage.
Samples
The Bowling Kata is a pretty good example.
SpecFlow Sample
Here is what the specification would look like in SpecFlow (again, this is great as an acceptance test, because it communicates directly with the business):
Feature File
The feature file is the common dialect for the test.
Feature: Score Calculation
In order to know my performance
As a player
I want the system to calculate my total score
Scenario: Gutter game
Given a new bowling game
When all of my balls are landing in the gutter
Then my total score should be 0
Step Definition File
The step definition file is the actual execution of the test, this file includes the mappings for SpecFlow
[Binding]
public class BowlingSteps
{
private Game _game;
[Given(#"a new bowling game")]
public void GivenANewBowlingGame()
{
_game = new Game();
}
[When(#"all of my balls are landing in the gutter")]
public void WhenAllOfMyBallsAreLandingInTheGutter()
{
_game.Frames = "00000000000000000000";
}
[Then(#"my total score should be (\d+)")]
public void ThenMyTotalScoreShouldBe(int score)
{
Assert.AreEqual(0, _game.Score);
}
}
NSpec Sample, xSpec, Context/Specification
Here is a NSpec example of the same bowling kata:
class describe_BowlingGame : nspec
{
Game game;
void before_each()
{
game = new Game();
}
void when_all_my_balls_land_in_the_gutter()
{
before = () =>
{
game.Frames = "00000000000000000000";
};
it["should have a score of 0"] = () => game.Score.should_be(0);
}
}
So Yea...SpecFlow is cool, NSpec is cool
As you do more and more BDD, you'll find that both the xBehave and xSpec flavors of BDD are needed. xBehave is more suited for Acceptance Tests, xSpec is more suited for unit tests and domain driven design.
Relevant Links
RSpec vs Cucumber (RSpec stories)
BDD with Cucumber and rspec - when is this redundant?
NSpec Project Site
Continuous Testing
Introduction to BDD and Mocking
BDD using NUnit and Moq
A true behavior driven tool would be something like Cucumber. We use it at my job against .NET code. This allows us to write features that define behavior of the system as a whole and we can then execute the features and verify that the system does what we expect. The whole process works very well for us.
http://cukes.info/
There is a .net implementation called NStep that connects to cucumber via the wire protocol, it allows you to write step definitions in C# using lambdas...its pretty awesome.
Step definitions look like this:
When("^I go to the \"([^\"]*)\" (?:[Ss]creen|[Pp]age)$", (string pageName) =>
{
var screen = ParseScreen(pageName);
GoToScreen(screen);
World.Browser.Wait(1000);
});
http://github.com/clearwavebuild/nStep
I think your understanding is in line with mine. BDD is more suited for integration testing and generally tests your system as the end user, eg:
Given I am an authorised user
When I go to the front page
Then there should be a link to my profile with my username as the link text.
There is no reason to not to unit test your repositories at a more granular level. I think both are useful and appropriate.
Can't I just use normal unit testing tools?
BDD is a process and mentality and so, yes, you can do it with any tools (or not, you can write your own without a tool if you want). However, the TDD tools had certain assumptions which cause some friction when trying to do things in a BDD way. For instance, TDD assumes you are testing an architectural unit of the software; class, module, service. Whereas BDD assumes you are specifying some functional portion of the system.
Should I use SpecFlow/Cucumber to describe lower-level components?
First of all, I think the question is a bit misguided. You wouldn't tend to describe components unless those components directly represent behavior. I'll still answer what I believe the spirit of the question is.
Story oriented tools like Cucumber are great for talking about behavior from a customer/user perspective. It can allow you to make specifications that are easily approachable by laymen. However, it can be tedious to describe large amounts or complex state with those tools.
Unit testing, or more code oriented specification tools like rSpec and Machine.Specification, can be a lot more convenient when dealing with complex or large state setups. You can use the various tools available to the languages to manage the state. Things like inheritance and fakes/mocks. Machine.Specification has some good approaches to this for the .NET minded.
So, should you use Cucumber to specify lower-level behavior? I'd say only if its important to have high levels of visibility for that particular behavior. On my current project, we've developed an architectural component to represent certain business-rule intensive portions of the system. Those components are specified with Cucumber, but the majority of system is covered with NUnit.
Btw, SpecFlow is really nice and approachable for .NET folks just getting into BDD, but eventually you'll want to graduate to full-blown Cucumber+nStep. The Cucumber ecosystem is HUGE and helpful. SpecFlow's is much smaller.
Also, the lambda syntax offered by nStep is quite a bit nicer than having to decorate methods a la SpecFlow or Cuke4Nuke.
Disclaimer/Background:
I did some of the original development on nStep but I'm using SpecFlow on my current project. I'm working to introduce BDD here and needed something simple and approachable.
It is interesting that this blog on Classifying BDD Tools talks about TDD and ATDD. As Liz Keogh points out: BDD is about conversation and exploration. The easier it is for all involved guys to contribute, communicate intension, share ideas, understand the others, etc. the faster we get to an adequate solution and the better software we build. When we finally follow the tool path, what are the tools that support collaboration between stakeholders of software projects best?
Based on the this blog on the differences between TDD, BDD, and ATDD I would say that there are at least three different flavors of BDD tool:
Unit Testing Frameworks
JUnit changed our view on development and testing. One of its strengths is that tests can be written in the same programming language as the application itself. Thus, we can build on the knowledge we already have in the delivery team. When the tests are even used to drive the development we reach the heaven of TDD.
Programming languages have been optimized to reduce redundancy, which is according to Ron Jeffries one of the worst sins of developers. Therefore, we often rely on these tools when we do technical testing to build the product right as they help us to be most efficient.
Several guys tried to make automated tests more understandable, as unit tests aren't really readable. One of the first attempts was to parse unit tests and provide a concise summary that is also readable to non-developers. For example TestDox / AgileDox creates simple documentation from the method names of JUnit test classes or Pickels generates documentation based on feature files written in Gherkin.
Frameworks such as MSpec help to write tests that are better readable and additionally provide readable output. These flavor of BDD tools focuses on human readable output, which enables the involvement of non-developers after the developers did their job.
Scenario Testing Frameworks
To involve stakeholders earlier in the development cycle, new tools were created that focus more on readable input. Cucumber utilizes plain text files to provide human readable inputs for automated tests. The text files contain scenarios written in a specially structured language based on the given-when-then structure. These frameworks are great tools that support collaborative definition of acceptance criteria.
Acceptance Testing Frameworks
In parallel to the BDD idea, another flavor of tools has been developed, where FIT was an early representative. This Framework for Integrated Test allows to specify examples within tables that are embedded into a documentation related to the examples. To write these documents no development skills are required and they can be easily read and reviewed by non technical guys as they are purely text based. Additionally, the text can be structured as the documents are not plain text files but the output of rich editors.
FitNesse allows to specify the expected behavior collaboratively based on a wiki. As wikis are easy to access and use, it has a low entry and learning curve, which propels the common work of the entire team. Many agile proponents emphasize that the best way for collaboration is face-to-face communication. But, if you write down what you have thought and discussed, it should be as rich and well structured as possible.
Concordion provides a lot of flexibility as you can describe your requirements in normal language using paragraphs, tables and proper punctuation. Any part of your description can be used as input to your automated tests and for the validation of the outputs of your system under test. As it is based on HTML you can structure your documents and integrate images. Simply, you have the expressiveness of the web to describe the expected behavior.
BDD should help to build the right product
You could implement BDD with all three flavors of tools, but each has its strengths and weaknesses. Unit testing frameworks and xSpec like tools perfectly use the strengths of programming. As they are tools from developers for developers, they are a perfect choice if you try to get the technical part right.
When you want to communicate the intention of the application you are probably better off with a tool that is strongly related with tools that editors use for their work. If a specification contains only inputs and expected outputs, anyone who reads it will have to reconstruct your ideas from the relation of inputs to expected outputs. A short description explaining the goal of a specification in the header helps the reader understand the structure of the specification. Documents based on specification-by-example could look like:
Yes, SpecFlow is cool, NSpec is cool ...
FitNesse and Concordion are cool as well
I've been reading this paper: Enforcing Strict Model-View Separation in Template Engines (PDF).
It contends that you only need four constructs within the views:
attribute reference
conditional template inclusion based upon presence/absence of an attribute
recursive template references
template application to a multi-valued attribute similar to lambda functions
and LISP’s map operator
No other logic is allowed within the view - for example if (attr < 5) would not be allowed, only if (valueLessThanFive)
Is this reasonable? Most MVC frameworks allow any logic within the views, which can lead to business logic creeping into the view. But is it really possible to get by with only those four constructs?
For "zebra striped" tables, the paper suggests mapping a list of templates onto the list of data - for example:
map(myList, [oddRowTemplate, evenRowTemplate])
But what if you want to make the first and last rows different styles? What if the 3rd row should be purple on Tuesdays because your graphic designer is mad? These are view-specific (for example if I was outputting the same data as XML I wouldn't use them) so don't seem to belong in the model or controller.
In summary:
Do you need logic above the four constructs listed above within views?
If so, how do you restrict business logic creeping in?
If not, how would you make the 3rd row purple on Tuesdays?
Terence Parr is a very smart guy and his paper has much to commend it, but from a practical point of view I have found using just these constructs somewhat limiting.
It is difficult to prevent business logic creeping in especially if you have the ability to do anything, as for example ASP.NET and JSP would give you. It boils down to how you spend your time:
Allow limited additional functionality (I'm not an advocate for "anything goes") and use code review mechanisms to ensure correct usage, or
Restrict to the four constructs above, and spend more time providing attributes like valueLessThanFive (remembering to rename it to valueLessThanSix when the business requirement changes, or adding valueMoreThanThree - it's a bit facetious as an example but I think you'll know what I'm getting at).
In practice, I find that allowing conditionals and looping constructs is beneficial, as is allowing property traversal such as attr[index].value in template expressions. That allows presentational logic to be effectively managed, while incurring only a small risk of misuse.
Allowing more functionality such as arbitrary method calls gets progressively more "dangerous" (in terms of facilitating misuse). It comes down, to some extent, to the development culture in place in your environment, the development processes, and the level of skill and experience in your team.
Another factor is whether, in your environment, you have the luxury of enforcing strict separation of work between presentation and logic, in terms of having dedicated non-programmer designers who would be fazed by advanced constructs in the template. In that event, you would likely be better off with the more restricted template functionality.
To answer your question about the 3rd row purple on Tuesdays:
The original (or one of the very early) MVC patterns had the 'View' being a data-view, there was no concept of a UI in the pattern. Modern versions of the MVC pattern have felt the need for this data-view which is why we have things like MVVM, MVP, even MV-poo. Once you can create a 'view' of your data that's specific to the UI View it's easier to solve lots of the concerns.
In our case our 'model' is going to get extra properties on it, such as Style or Colour (style is better as it still lets the view define how that style is represented). The controller will take raw 'model' items and present to the view custom 'model' items with this extra Style, giving the 3rd row on Tuesdays a style of 'MadDesignerSpecial', which the view uses to apply the purple colour.
How do YOU factor your Domain (namespaces), in Domain Driven Design?
I have been moving to the following concept:
Project.Entity
Project.Entity.Abstracts
Project.Entity.Entities
Project.Entity.Extensions
Project.Entity.Immutables
Project.Entity.Interfaces
Project.Entity.Repositories
For example, I have an entity in a CMS called "Content". So, I would create a project called Project.Content, and factor the classes to look like:
interface IContent
class Content : IContent
interface IContentRepository
class ContentRepository : IContentRepository
This "Content" Entity model would have its own namespace.
But, I am finding it does not scale well in a large Enterprise environment with well over a dozen projects (try 18) of "Entity" models. I end up with a solution with over a dozen projects, some of which only have 2 or 3 classes (i.e. UrlRewriter). Also, I find myself referencing other projects just for their Interfaces. I feel like this is poluting my domain; while not concret references, it's sometimes difficult to keep from circular references.
So, I fall back to the "Layer" concept at times...
I am wanting to know how other DDD experts are factoring Enterprise-size applications. Please feel free to recommend books and articles.
And thanks in advance!
One think that I do is to add something that identifies the bounded context to it.
Ps. to make sure it is clear why, check both links on bounded context:
http://dddcommunity.org/discussion/messageboardarchive/BoundedContext.html, http://devlicio.us/blogs/casey/archive/2009/02/11/ddd-bounded-contexts.aspx
I use follow the .NET guidelines. I find them very intuitive and they allow you to setup namespaces such that you don't need to import anything you don't need.
I would never impose a strict naming convention for the feature level. The design of each different project should guide that.
I similarily to you have found out that having load of projects becomes a pain to manage.
I prefer the
Project.Domain
Project.DataAccess
Project.Presentation (presenters and such)
Project.Gui (in case of a winforms app)
setup.
In a way making things simple helps a lot when things go bad.
The question is what do you gain when you create another project ? (it is very easy to do so, almost to easy)
Will you ever want to use that project independently or not ? You might end up with the resulting .dlls so coupled you can't even deploy them without being exactly the same versions etc. in that case there is little reason for splitting it up and cluttering your IDE)
You can always move things to a new project later if the need arises, it is somewhat painfull, but by that time you would have a good reason to do it apart from just the feeling that is the way it is done.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
While going through university and from following the development of SO, I've heard a lot about the Model-View-Controller architectural design pattern. I inadvertently used the MVC pattern even before I knew what it was, and still use it in my everyday job. From what I've seen, it's probably the most popular pattern used today. What I haven't heard much about though, are the alternative patterns you can use instead of MVC. What options are there, and for what reasons would you decide to use them over MVC? I'm also interested in knowing the types of systems they are typical of being used for. Finally, what are the pros and cons that come along with using them?
Passive View - http://martinfowler.com/eaaDev/PassiveScreen.html
Supervising Controller - http://martinfowler.com/eaaDev/SupervisingPresenter.html
Model-View-Presenter - http://martinfowler.com/eaaDev/ModelViewPresenter.html
My personal favorite is the Passive View. More testable than others I've seen including MVC.
Some other architectural patterns including MVC.
Layered Systems
TCP/IP
Object-Oriented Organization
Model-View-Controller, Presentation-abstraction-control, Model View Presenter and Model View ViewModel.
Examples would be ASP.NET's MVC, Ruby on Rails, and bunch of others.
Event Based, Implicit invocation
Browser environment (DOM)
Pipe and filter architecture
Unix pipes
Repositories
Table Driven Interpreters
You may also find this paper by Garlan & Shaw on Software Architecture a nice read.
Another noteworthy link would be the article on architectural patterns at Wikipedia.
I've occasionally seen MVC without the C, where the view listens for changes in the model's data and alters rendering accordingly, and where the methods in the model are bound to event handlers for the view.
For projects where the view is by necessity tightly couple with the data (such as when there are visual components that directly relate to the model or attributes of the model), this can be rather useful, as it cuts out the "middle man."
I think many would argue, though, that this is still MVC, just a hybridized version, and that the bindings established between the view and model are controller logic.
Well, there's Model-View-Presenter, but I think you'll find that the most common "alternative" to MVC is really a lack of proper separation. As an extreme example, consider classic ASP pages where HTML, VBScript and SQL are found side-by-side in the same file. (That's not a bash of ASP — you'll find plenty of such examples in other languages.)
Although the above answers are quite correct, I think it's much more important to note that the words "design pattern" are completely unknown to 90% of all people who create software. They just start writing code.
The challenge is not selecting the best design approach, it's convincing others that design has value.
Well it is quite old now. I would like to mention one more (in the interest of info for additional knowledge) is PresenterFirst patrern
Here is more information on the same:
http://en.wikipedia.org/wiki/Presenter_First
http://www.atomicobject.com/pages/Presenter+First
HTH
The Presentation-Abstraction-Control (PAC) family of patterns, where interface/interaction is handled by a hierarchy of agents.
The wikipedia article is not great
http://en.m.wikipedia.org/wiki/Presentation-abstraction-control
In the Lift web framework we use a View First approach. Basically a view is composed of one or more snippets (somewhat similar to controllers) and snippets can be nested. This works very well with HTML and Scala's built-in XML processing capabilities.
You can roll your own MVC with the current ASP.NET framework and still keep the postback model.
http://www.codeproject.com/KB/aspnet/RollingYourOwnMVCwithASP.aspx
What about the Observer pattern. If I am not mistaken , MVC was introduced in Smalltalk and thereafter several publish/ subscribe patterns have come into picture.
The observer pattern (a subset of the publish/subscribe pattern) is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.
Ex : The Save button gets enabled in an editior, only when there is data to be saved. Another example of the observer pattern is Document View architecture in MFC, where in the view gets updated when the document changes .