Separation of concerns; MVC; why?

Question

I\'m currently reading up on OO before I embark upon my next major project. To give you some quick background, I\'m a PHP developer, working on web applications.

On

Answer 1

I am not sure I can lead you to the water you wat to drink, but I think I can answer some of your concerns.

First, in MVC, the model and the view do have some interplay, but the view is really coupled to contract and not to implementation. You can shift out to other models that adhere to the same contract and still be able to use the view. And, if you think about it, it makes sense. A user has a first name and last name. He probably also has a logon name and a password, although you might or might not tie this to the "contract" of what a user is. The point is, once you determine what a user is, it is unlikely to change much. You might add something to it, but it is unlikely you are going to take away that often.

In the view, you have pointers to the model that adheres to that contract, but I can use a simple object:

 public class User
 {
    public string FirstName;
    public string LastName;
 }

Yes, I realize public fields are bad. :-) I can also use a DataTable as a model, as long as it exposes FirstName and LastName. That may not be the best example, but the point is the model is not tied to the view. The view is tied to a contract and the particular model adheres to that contract.

I have not heard of every object must have its own UI. There are essentially two types of objects: state and behavior. I have seen examples that have both state and behavior, but they generally are in systems that are not very testable, which I am not fond of. Ultimately, every state object should be exposed to some form of UI to avoid forcing IT people to handle all the updates directly in a data store, perhaps, but have their own UI? I would have to see that written in an explanation to try to understand what the user is doing.

As for SoC, the reasaon to package things distinctly is the ability to switch out layers/tiers without rewriting the entire system. In general, the app is really located in the business tier, so that part cannot as easily be switched out. The data and UI should be fairly easy to switch out in a well designed system.

As far as books on understanding OOP, I tend to like books on patterns, as they are more practical ways of understanding the concepts. You can find the primer material on the web. If you want a language agnostic pattern book, and think a bit geeky, the Gang of Four book is a good place to start. For more creative types, I would say Heads Up Design Patterns.

Answer 2

I don't know any good books on the MVC subject, but from my own experience. In web development for example, many times you work with designers and sometimes dbas. Separating the logic from the presentation allows you to work with people with different skill sets better because the designer doesn't need to much about coding and vice versa. Also, for the concept of DRY, you can make your code less repetitive and easier to maintain. Your code will be more reusable and make your job a lot easier. It will also make you a better developer because you will become more organized and think of programming in a different way. So even if you have to work on something that is not MVC, you might have a different approach to architecting the project because you understand the MVC concepts.

I guess the tradeoff with a lot of MVC frameworks for large sites is that it may not be fast enough to handle the load.