I just found the MVC was initially proposed in 88 [here is the pdf file] but unfortunately ASP.NET just recently implement it.
Do you know which is the most used MVC design pattern in the our days frameworks? I'm curious to know how MVC has evolved during the times and which is the best approach(what make it a good approach)? For example: a) in some versions, views doesn't interact with models. b) model has to be bigger than controller. On short, which are the gold rules for a good MVC implementation even if a certain framework doesn't require it?
As far as MVC design patterns it's been in use for more than 20 years in a wide variety of various languages and frameworks.
It's either being used in or is the basis of the design patterns being used in a wide variety of applications.
The core of MVC has to do with separating your code so that things have a logical progression through your code and gives you a simple way to separate your code. I'm not sure I understand your question about wanting to know which is the most used MVC design pattern since it is the design pattern.
According to Wikipedia, it was first described in 1979, not '88. The paper you link to even has a reference at the end titled "Model View Controller" from 1987, which is a good hint that 1988 was not the first proposal. :-)
I don't think it's "unfortunate" so much as "inevitable" that big companies didn't get around to implementing it for decades. Big companies tend to move slowly.
Sorry, was there a question here?
Related
I roughly know how to make a mvc uml class diagram en can find enough info/ examples on the internet. The only thing i cant find info about is if it makes a difference when you have a jacascript controller/model and a c# controller/model.
In general: no.
UML is technology independent. Most models don't assume the technology. MVC can also be applied to different programming languages.
You only need to be aware that there are some concepts that are not handled by particular languages. The only thing that comes to my mind here is multiinheritance. Just use interfaces instead of (eventual) multiinheritance and there'll be no problem.
I can also imagine that some details can be designed in different ways to achieve better performance, but you'd need to know both languages perfectly to be able to make such decisions.
So don't bother about specific language and your diagram will be fine.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The Model View Controller concept is expressed all over the place as an important thing to keep in mind when developing an application. But when developing applications, I struggle to distinguish whether or not I'm using the MVC model and whether or not that is hurting my application. Why is the MVC concept important in application development and how does it help developers make better programs?
Well, like doing many things in life, it always helpful to be well organized. Models, Views and Controllers are distinctly different pieces of code that helps to provide different functions to your overall project. Because of that, they are kept separate and organized.
Imagine if you were designing a program. You wouldn't put all your code into one function, would you? No, you would divide them up into separate smaller functions that solve very specific tasks. Likewise, as programmers, we're constantly looking for ways to separate and divide our large applications to smaller bits of pieces. One of these organization design patterns is MVC, where, the model (the data) exists in one section, the view (the UI) exist in one section, and the controller (logic) exists in another section.
What problems does this solve? Well, just as how having separated functions solve the problems of readability, modularity, and coupling, so does MVC. Say if you wanted to change a piece of code, you can tackle it in a smaller subset that is more or less isolated from the larger piece of code. This allows you to add, modify or remove code more effeciently and logically. It also helps in testing, since similar code is sectioned into groups, you may be able to have better coverage of your tests cases. Also very important is that you end up writing a lot less code.
Hope this helps.
Have you heard of "separation of concerns"? MVC, in simple terms, is an architecture that allows different parts of a system to be loosely coupled (or separated). Views are typically dumb and display data and take user actions. Models represent the data and domain logic in your system. And controllers liaise between the View and the Model, often controlling flow. There are loads of variants on the original Smalltalk MVC pattern and nowadays it seems like every framework is MVC.
The advantages are it makes your code less fragile, easier to understand and change and easier to unit test. All because it is separated into different parts.
A good example is that I recently changed job and started working on a new project in PHP (I come from .NET background). The learning curve was much easier because we use an MVC framework. Because I already knew the pattern, I knew where everything "was", as such, and how the system was put together.
http://en.wikipedia.org/wiki/Model–view–controller
https://gamedev.stackexchange.com/questions/5372/mvc-like-compartmentalization-in-games
That's a question you'll understand once you've experienced a few software development projects...
Most prominently, it separates code into logical areas. UI code is kept in the UI (View), business logic is kept in the Controller, and objects are kept in the Model. If you need to update the UI, create a different UI (such as web interface), create web services or what not, then you don't need to spend forever and a day dissecting a tangled mash of incomprehensible code. You can also get different member of a team to specialise in a certain area, such as the UI or model, and this can lead to more robust code or perhaps allow a junior developed to work on something less complicated than the whole picture.
Here's an old post from pre-MVC Framework days when I worked with the Microsoft Web Client Software Factory (based on MVC... or MVPC... or whatever):
http://www.xosoftware.co.uk/post/2010/02/02/Design-Patterns-(As-Used-in-the-Web-Client-Software-Factory-WCSF).aspx
You are separating software components and creating a design that is loosely coupled. This will allow for easier maintenance, easier to read and shorter code, flexibility, and expand-ability. Many things follow this design patter (websites, mobile apps, ect.)
I can promise you learning it is well worth your time. I would suggest jumping in and starting with something simple like (CodeIgniter, PHPBlueprint) just to get your feet wet and see an MVC work.
A good book to checkout would be Head First Design Patterns.
I am developing my system with helper classes and I see on several sources that say "Helper classes" are not recommended in object orientated programming.
If so, why are they considered bad?
How do they play in with the MVC framework of Codeigniter?
Thanks
The strength and weakness of the helpers is that they don't neatly fit into the MVC framework; they're more like glue than wood or steel framing. They can be convenient to use in several contexts and are well-suited for common, light tasks. If your helpers become more complex and start needing to interact with models and controllers, odds are you've got a questionable design that needs to be more carefully considered. Glue and duct tape may be useful, but you'll be hard-pressed to find a skyscraper made of them.
I need to give a short presentation (2-4 hours) on Test-Driven Development and need to come up with a small class that I can build using the TDD methodology. The class has to be relatively small, but "sell" the concept of TDD.
If anyone has read James Newkirk's book, Test-Driven Development for in Microsoft.Net, the Stack example is perfect. It’s a small class, has a manageable list of tests/requirements, and the creation process sells TDD (IMHO).
I don't want to use the Stack example or similar data structures (queue, lists, etc) for fear on impinging on Newkirk’s work.
So, I’m looking for a few good ideas for a sample class.
Thanks.
How about using the 1st section of Kent Beck's Money example. It starts out very simply but when you arrive at addition of two different currencies, TDD suddenly shows you the falisity of up front design, or YAGNI (you aren't going to need it).
Another good example is uncle Bob's bowling score TDD example. I think this is a good example of how a TDD narrative brings you to a clean solution that would have been explicitly unapproachable via an up front design.
To make it a really exciting presentation, up-front you could challenge the audience to design the two scenarios using whatever methods they find appropriate. You then would show the TDD way of designing them.
The real WTF moment for me with TDD was when Beck removed the two subclasses of Money, and the tests worked. This is not a trivial action; the man deleted two classes! The confidence to do something like this can be found only by two means.
1) gathering all the senior players in a code base and running through scenarios, followed by an extensive follow through to confirm it works
2) TDD
=D
If you have time for it, I would pick an example with an external dependency of some sort that is going to get abstracted in the test. Either a database, calls to a GUI, calls to a remote system, etc.
The reason is that one of the blocks to TDD is that the example seems too self contained. "Sure, when everything is a self-contained unit you can unit test, but when I have 15 systems to integrate, what is the point?" kind of thing.
I would also at least show one example at the end (look at Michael Feather's book Working Effectively with Legacy Code for how-tos) of migrating an existing class to bring it under TDD. Don't dwell on that as an example, but odds are your audience will be thinking about how to migrate the class they wrote that morning, no reason to let that fester as an "unmentionable."
TDD problems has a list of problems, ranging from simple to less simple.
Some have a list of tests to start from no solution yet.
If you have a perfect example from a book, then you should use it and promote the book. No author would object to that.
Aside from that, I attended a TDD presentation a few years ago where the example was a simple calculator and it worked beautifully.
Three I like, in roughly increasing order of difficulty:
Range (of integers; implement
isEmpty(), contains(), intersects(),
length())
Natural Sort
Snake
If I had half an hour, I'd do Range; 90 minutes, probably Natural Sort; more: Snake. Depends on the audience, though.
I would try to find something small from a wellknown domain. I recently gave a presentation on BDD / TDD based on ASPNET.MVC. That included one controller, one action and a view model. That also gave me the opportunity to introduce a dependency container and a mocking framework.
How about a simple math class, with addition, subtraction, multiplication, and such?
Another classical example from the TDD / Extreme / Agile community is the Bowling Game example; I seem to recall it has been used in both Beck and Martin, as well as multiple times at xprogramming.com for examples and explorations of different techniques within TDD.
Go out on a limb and take requests from the audience. :)
If the goal is selling TDD, you also want to show a small refactoring of a large test base. It is easy to make it work with small samples, most developers buy into that now. There is much more doubt about scalability. An avanced topic would then be how to handle a large base of legacy (no unit tests) code.
A simple card game would be nice, especially as you can provide some visual representation of the result
And I assume you are going to use a coding dojo as presentation form, aren't you? No fancy powerpoint. If the public is non-programmers, use the excel sample
Essential Skills for Agile Development - Ka Iok Tong. This book is about Agile but containing several chapters about test especially TDD. The author explains TDD by coding from requirement, also note down his thought on how to solve problem in TDD. You may find this book here. To update more about concept and modern tools you may go here
I'd suggest you buy yourself the book Test driven design by example from Kent Beck.
The book almost completely focuses on building one class through TDD.
Roman numerals. Count non-comment lines of source code. Towers of Hanoi. There's plenty of ideas out there.
If the intended audience is naive in TDD then I would recommend using below examples. It really gives you good understanding of TDD concepts and implementation.
Bank Account
Bowling Game
I'm looking for patterns that concern coding parts of a GUI. Not as global as MVC, that I'm quite familiar with, but patterns and good ideas and best practices concerning single controls and inputs.
Let say I want to make a control that display some objects that may overlap. Now if I click on an object, I need to find out what to do (Just finding the object I can do in several ways, such as an quad-tree and Z-order, thats not the problem). And also I might hold down a modifier key, or some object is active from the beginning, making the selection or whatever a bit more complicated. Should I have an object instance representing a screen object, handle the user-action when clicked, or a master class. etc.. What kind of patterns or solutions are there for problems like this?
I think to be honest you a better just boning up on your standard design patterns and applying them to the individual problems that you face in developing your UI.
While there are common UI "themes" (such as dealing with modifier keys) the actual implementation may vary widely.
I have O'Reilly's Head First Design Patterns and The Poster, which I have found invaluable!
Shameless Plug : These links are using my associates ID.
Object-Oriented Design and Patterns by Cay Horstmann has a chapter entitled "Patterns and GUI Programming". In that chapter, Horstmann touches on the following patterns:
Observer Layout Managers and the
Strategy Pattern Components,
Containers, and the Composite Pattern
Scroll Bars and the Decorator Pattern
I don't think the that benefit of design patterns come from trying to find a design pattern to fit a problem. You can however use some heuristics to help clean up your design in this quite a bit, like keeping the UI as decoupled as possible from the rest of the objects in your system.
There is a pattern that might help out in this case, the Observer Pattern.
I know you said not as global as MVC, but there are some variations on MVC - specifically HMVC and PAC - which I think can answer questions such as the ones you pose.
Other than that, try to write new code "in the spirit" of existing patterns even if you don't apply them directly.
perhaps you're looking for something like the 'MouseTrap' which I saw in some articles on codeproject (search for UI Platform)?
I also found this series very useful http://codebetter.com/jeremymiller/2007/07/26/the-build-your-own-cab-series-table-of-contents/ where you might have a look at embedded controllers etc.
Micha.
You are looking at a professional application programming. I searched for tips and tricks a long time, without success. Unfortunately you will not find anything useful, it is a complicated topic and only with many years of experience you will be able to understand how to write efficiently an application. For example, almost every program opens a file, extracts information, shows it in different forms, allow processing, saving, ... but nobody explains exactly what the good strategy is and so on. Further, if you are writing a big application, you need to look at some strategies to reduce your compilation time (otherwise you will wait hours at every compilation). Impls idioms in C++ help you for example. And then there is a lot more. For this reason software developers are well paid and there are so many jobs :-)