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.
Related
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
I am new in web development, and read some wiki and discussions about MVC. However, the more I read, the more confusion I have about its design purpose.
I just want to know why is this design pattern invented? And what problem is it used to solve?
Thanks in advance.
The goal of the MVC paradigm is in essence to ensure a form of separation of code. The problem that often arise when developing code is that the code is written in a succession, where each part follows another and where each part is directly dependent upon what the other parts are doing.
When working with a large project, maintaining and further developing the code can quickly become an issue. You could therefore argue, in a simplified manner, that what the MVC paradigm tries to do is to ensure that you separate business logic (e.g. the code that performs) from the presentation logic (the code that shows the results). But those two parts need to communicate with each other, which is what the controller is responsible for.
This allows for a clear structure of code where the different parts are more decoupled, meaning less dependent upon each other.
The separation also means that you work in a much more modular way, where each part interacts with the others through an interface (some defined functions and variables that are used to call upon other parts) so that you can change the underlying functionality without having the change other parts of your code, as long as your interface remains the same.
So the problem it tries to solve is to avoid having a code base that is so entangled that you can't change or add anything without breaking the code, meaning you have to modify the code in all sorts of places beyond where you made your original changes.
To some degree it's a solution in search of a problem.
As a rather ancient programmer I'm well aware of the benefits of "separation of concerns", but (in my not-so-humble opinion) MVC doesn't do this very well, especially when implemented "cook-book" fashion. Very often it just leads to a proliferation of modules, with three separate modules for every function, and no common code or common theme to tie things together and accomplish the real goal: minimize complexity and maximize reliability/maintainability.
"Classical" MVC is especially inappropriate in your typical phone GUI app, where, eg, management of a database table may be intimately connected to management of a corresponding table view. Spreading the logic out among three different modules only makes things more complicated and harder to maintain.
What does often work well is to think about your data and understand what sorts of updates and queries will be required, then build a "wrapper" for the database (or whatever data storage you use), to "abstract" it and minimize the interactions between the DB and the rest of the system. But planning this is hard, and a significant amount of trial and error is often required -- definitely not cook-book.
Similarly you can sometimes abstract other areas, but abstracting, say, a GUI interface is often too difficult to be worthwhile -- don't just write "wrappers" to say you did it.
Keep in mind that the authors of databases, GUI systems, app flow control mechanisms, etc, have already put considerable effort (sometimes too much) into abstracting those interfaces, so your further "abstraction" is often little more than an extra layer of calls (especially if you take the cook-book approach).
Model view controller was created to separate concerns in code instead of crating a hodge podge all in a single blob. (Spaghetti code) the view code is merely presentation logic, the model is your objects representing your domain and the controller handle negotiating business logic and integrations to services on the backend.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have known enough about programming to get me in trouble for about 10 years now. I have no formal education, though I've read many books on the subject for various languages. The language I am primarily focused on now would be PHP, at least for the scale of things I am doing now.
I have used some OOP classes for a while, but never took the dive into understanding the principles behind the scenes. I am still not at the level I would like to be expression-wise, but my recent reading of the book The OOP Thought Process has left me wanting to advance my programming skills.
With motivation from the new concepts, I've started a new project. I've coded some re-usable classes that deal with user auth, user profiles, database interfacing, and some other stuff I use regularly on most projects.
Now having split my typical garbled spaghetti-bowl mess of code into somewhat organized files, I've been having some problems when it comes to making sure files are all included when they need to be, how to logically divide the scripts up into classes, and how segmented I should be making each class.
What I'm really asking for is advice or suggested reading that focuses not on specific functions and formats of code, but on the logical layout of projects that are larger than just a hobby project.
I want to learn how to do things properly, and while I am still learning in some areas, this is something that I have no clue about other than just being creative, and trial/error. Mostly error.
Thanks for any replies. This place is great.
I will try to express my experience from previous projects here, maybe they help you.
If you try to segment your project, try to find components that might be useful as themselves. If you write e.g. a database layer, think about what to do to make the database layer independent from the rest of your application (except utility classes and configuration). If you write a RichClient that accesses the database layer, try to put exactly the stuff you need in it which you would also need when accessing it from a Web layer. Now you have a component that would maybe even useful in a command line client.
Or if you want to see this from a lower level, split your application into small units, and don't let these units have circular dependencies!!! If two components have circular dependencies, they cannot be splitted and should really be a single component. I know, I broke this rule some times because you cannot hold it up always, but it is a good rule to get understanding of the building blocks of your app.
Another popular dividing rule of an application is the Model-View-Control Pattern (MVC), which states that the Model (the data classes), the Control (the logic of your program) and the View (The graphical user interface) should be splittet into distinct packages. While I adhere to this, I would divide my code like this. Within each package I have distinct model, view and control classes, but the model classes don't know anything about the control layer, and the control layer does not know anything about the GUI.
Since GUI development is always tedious, and therefore often the least tested part (at least in unit tests) of an application, splitting it from the control make writing the buisiness logic a lot easier. In fact, it lets you concentrate on what you have to do, which is getting work done, which you code in buisiness logic. If this part works, you can spend time writing a nice GUI for it. Of course will the GUI and ease of use often bring their own requirements to the control, but at least its loosely coupled.
In my current large project we have some bit components, which we now see as independent products, which get used by the really product. This makes testing and writing the independent component easier for the person in charge, and gives everyone a more stable component.
Just my 2¢.
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 11 years ago.
I have a question which is not strictly-speaking programming related, but nevertheless caused by being an analyst and a programmer at the same time.
It's about starting new projects which seem to be unfeasible, because they have an unknown domain, lack specifications, and/or require technology which I am not familiar with. I get some sort of panic when I approach such a project, and then relax as I proceed along with domain and technology understanding.
Is this something you experience? How do you cope with it?
The best way that I know of to try to contain and control the human factors in a project is to have a clear idea of your own processes.
Start with some Domain Driven Design, work with the users and help them to understand their domain and the business processes that surround the domain. Often developers are far better at abstraction than the managers/business people so we can often help them to understand their own domain.
Build up a set of acceptance criteria, these form your tests which actually form your spec.
Once you have an idea of the above you know much more about feasibility and how long it will take (and even if the technology that has been specified is the right one)
As for approaching new technologies, start small, build a proof of concept and make your mistakes there rather than on production code. There is a huge amount of best practice on the web and places like StackOverflow are good places to start.
I would suggest working in an agile fashion, get the project owners to prioritise the work that needs to be done, work out what is needed for the next two week sprint and deliver it (which may mean stubbing out a lot of functionality). They'll tell you when it is wrong and it may influence their own decision making.
Don't view the entire project as a nasty whole, break it down into deliverable sections and one step at a time.
Calm down.
If the project is initially infeasible (even if only in your own mind) then start with a feasibility study. This is a sub-project with which you will define the project (or at least the next sub-project).
You've already defined several major tasks within the feasibility study: learn about the domain, write some specifications, learn enough about the new technologies.
As for me, no I never panic about this sort of situation, I love starting with a blank sheet of paper, and experience has taught me how to start filling it in real quick.
So, take a few deep calming breaths and jump in.
Yep, I get this felling all the time. But I always think that technologies are like tools. Once you got how to handle then, the rest will be easy.
Whenever I don't feel like that is when disaster lurks! It's like eating an elephant, just do it one bite at a time. Do some part you do understand, and that gives a handle to the next bit.
unfeasible,
unknown domain,
lack specifications,
require technology which I am not familiar with
I think that's how we start our life too. As long as you are confident that you can pull it off, just stick to it and you will see that things are working in your favor provided:
You understand the importance of being Self Starter
You take responsibility for who you are
You ask the right questions at right time
All the best!!!
Often the trouble with these infeasible projects is that the client is on a limited budget and will go bust before you complete your feasibility study. In this case it might be worth taking a step back from technology and looking at economics. May be sub-contracting to someone with the required knowledge will ease the pain.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Agile emphasizes quick iterations without wasteful planning.
MVC emphasizes separation of concerns based on a planned architecture.
Since non-MVC technologies require less planning, could they be more appropriate in an Agile project?
Separation of concerns does not necessitate that you plan out every detail before you start coding. And agile does not mean that you just write the code down as it comes to mind. Agile means not being too attached to your initial idea of what the project will look like and to be ready to refactor should the need arise (as it usually does), not being afraid to throw big pieces of code out in the process.
Separation of concerns can very well make refactoring a lot easier, so MVC can be a big helper of agility.
Agile development is typically a process of rapid prototyping and refactoring. MVC's separation of concerns can often make both processes easier and faster.
Design patterns are a fundamental part of quick development. Popular design patterns are popular because they have wide utility. Relying heavily on patterns can make a workable architecture for a project crystallize much more quickly. The common vocabulary afforded by design patterns make it easier for a team to communicate the structures of a project and focus on the domain specific issues. Should one pattern turn out to be inconvenient for the progress of the project, the relation ship that pattern has with other alternatives are likely well understood, simplifying the task of refactoring to an alternative layout.
That being said, the MVC pattern has tremendous gravity. One of the major reasons it works so well is that it tends to emphasize API's. This sort of isolation makes it much easier to change certain parts of a system without having a major effect on unrelated parts. If a layer of the system has a defect, it's normally easy to alter that layer without affecting other layers, because they are separated by a well defined API. If an API is itself deficient, then it is often possible to alter the API exposed without effecting the actual logic of either layer (Although this tends to be more difficult than the first kind of deficiency).
When you find the right balance between structure and flexibility, it's worth its weight in gold.
I tend not to like most (current) MVC paradigms, because I believe they introduce pointless abstraction, reinvent the wheel, and add a lot of rigidity.
But I also tend to have highly structured programs that separate content from business logic from data access, and have as few "configurations" as possible in order to accomplish 1 thing. Ideally, to accomplish 1 thing, you should only have to edit 1-2 things.
Needless abstraction is the root of many problems.
The key phrase in agile is 'the simplest thing that could possibly work'.
If the simplest solution to a problem is:
a single script
a single web page
a single installation of a standard tool like a wiki
a single-user single-database 'just edit the data' editor
Then those won't have MVC, and will be the appropriate agile solutions.
If it is obvious from the start of the project that nothing like that is going to come close to solving the problem, it would be pointlessly literal process-following to try them and wait to fail before trying the next simplest solution.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
In my experience, UI programming is very time consuming, expensive (designers, graphics, etc) and error prone - and by definition UI bugs or glitches are very visible embarasing.
What do you do to mitigate this problem?
Do you know of a solution that can automatically convert an API to a user interface (preferably a Web user interface?).
Probably something like a JMX console
with good defaults
can be tweaked with css
where fields can be configured to be radio button or drop down list, text field or text area, etc
localizable
etc
Developing UI is time consuming and error-prone because it involves design. Not just visual or sound design, but more importantly interaction design. A good API is always interaction model neutral, meaning it puts minimal constraints on actual workflow, localisation and info representation. The main driver behind this is encapsulation and code re-use.
As a result it is impossible to extract enough information from API alone to construct a good user interface tailored to a specific case of API use.
However there are UI generators that normally produce CRUD screens based on a given API. Needless to say that such generated UI's are not very well-suited for frequent users with demands for higher UI efficiency, nor are they particularly easy to learn in case of a larger system since they don't really communicate system image or interaction sequence well.
It takes a lot of effort to create a good UI because it needs to be designed according to specific user needs and not because of some mundane API-UI conversion task that can be fully automated.
To speed the process of building UI up and mitigate risks it is possible to suggest either involving UI professionals or learning more about the job yourself. Unfortunatelly, there is no shortcut or magic wand, so to speak that will produce a quality UI based entirely and only on an API without lots of additional info and analysis.
Please also see an excellent question: "Why is good UI design so hard for some developers?" that has some very insightful and valuable answers, specifically:
Shameless plug for my own answer.
Great answer by Karl Fast.
I don't believe UI programming is more time consuming than any other sort of programming, nor is it more error prone. However, bugs in the UI are often more obvious. Spotting an error in a compiler is often much more tricky.
One clear difference between UI programming is that you have a person at the other end, instead of another program, which is very often the case when you're writing compilers, protocol parsers, debuggers, and other code which talks to other programs and computers. This means that the entity you're communicating with is not well-specified and may behave very erratically.
EDIT: "unpredictable" is probably a more appropriate term. /Jesper
Your question of converting an API to a user interface just doesn't make sense to me. What are you talking about?
Looks like you are looking for the 'Naked Objects' Architectual pattern. There are various implementations available.
http://en.wikipedia.org/wiki/Naked_objects
I'm not providing a solution, but I'll attempt to answer the why.
So I don't speak for everyone, but for me at least, I believe one reason is because programmers tend to concentrate on functionality more so than usability and they tend not to be too artistic. I think they just tend to have a different type of creativity. I find that it takes me a long to time to create the right graphics, compared to how long it takes me to write the code (Though, for the most part, I haven't done any projects with too many graphical requirements).
Automatically generating user interfaces may be possible to some extent, in that it can generate controls for the required input and output of data. But UI design is much more involved than simply putting the required controls onto a screen. In order to create a usable, user friendly UI, knowledge from disciplines such as graphics design, ergonomics, psychology, etc. has to be combined. There is a reason that human-computer interaction is becoming a discipline of its own: its not trivial to create a decent UI.
So I don't think there's a real solution to your problem. UI design is a complex task that simply takes time to do properly. The only area where it is relatively easy to win some time is with the tooling: if you have powerful tools to implement the design of the user interface, you don't have to hand-code every pixel of the UI yourself.
You are absolutely correct when you say that UI is time consuming, costly and error prone!
A great compromise I have found is as follows...
I realized that a lot of data (if not most) can be presented using a simple table (such as a JTable), rather than continuously try to create custom panels and fancy GUI's. It doesn't seem obvious at first, but it's quite decent, usable and visually appealing.
Why is it so fast? Because I was able to create a reusable framework which can accept a collection of concrete models and with little to no effort can render all these models within the table. So much code-reuse, its unbelievable.
By adding a toolbar above the window, my framework can add to, remove from or edit entries in the table. Using the full power of JTables, I can hide (by filtering) and sort as needed by extending various classes (but only if/when this is required).
I find myself reusing a heck of a lot of code every time I want to display and manage new models. I make extensive use of icons (per column, rows or cells, etc) to beautify the screens. I use large icons as a window header to make each screen 'appear' different and appealing and it always looks like new and different screens, but its always the same code behind them.
A lot of work and effort was required at first to do the framework, but now its paying off big time.
I can write the GUI for an entirely new application with as many as 30 to 50 different models, consisting of as many screens in a fraction of the time it would take me using the 'custom UI method'.
I would recommend you evaluate and explore this approach!
if you already know or could learn to use Ruby on Rails, ActiveScaffold is excellent for this.
One reason is that we don't have a well-developed pattern for UTDD - User Test Driven Development. Nor have I seen many good examples of mapping User Stories to Unit Tests. Why, for example, do so few tutorials discuss User Stories?
ASP.NET Dynamic Data is something that you should investigate. It meets most, if not all your requirements
It's hard because most users/customers are dumb and can't think straight! :)
It's time consuming because UI devs/designers are so obsessive-compulsive! :)