Mariano Kamp
Unregistered
|
|
Hi,
this is really great stuff - I wish I would be able to get a point across so sharply.
For me the interesting thing about your publications is that you often cover a view angle which you don't find very often. It's a very good experience to reconsider the current way of thinking and the almost verbose examples help a lot to understand the simplicity of this essential ideas.
Second good and related point is that especially this article refocuses on things I use every day and didn't pay a lot of attention to anymore. I would appreciate being able to step back all by myself and find these simple truthes just from observing what I am doing, but often lacking this ability the second best is reading one your articles ;-)
The level of detail and abstraction is great. One obstacle in looking back at basic concepts once learned in the past is, that they are almost always explained for real beginners and after reading the first sentences it is really hard to keep my eyes open, not so here.
I remember reading one of your articles one or two years back, about why MVC is fundamentally flawed, yet I have to come to believe it. I would agree with most of what you described then and reiterated in this article, but two things keep me puzzled.
a) Putting the representation of an object into the object forces high coupling, doesn't it. I understand that this also some kind of cohesion and they should be close when looking at their close relationship, but especially the last is my concern. One object can be rendered to HTML / WML / Swing / a voice operated telephone. It's obvious that it doesn't make any sense to put render engines for each of those "views" into the object. Even if you delegate the actual rendering to someplace else you need to provide the defining data to it, but then we are at mvc again.
At the end of the day it is just one way to partition the application. And one way which is widely accepted and used. This leads me to ...
b) .. the real world. I know, one can dream and if that is the only thing you wanted to get across, to understand the drawbacks of MVC, that'll be fine with me, but if not I'd like to know how you apply this in your working practice as a consultant.
I am working as a consultant myself and I am very happy if the people I am working with know at least MVC. This is one thing, which is build into a lot of frameworks and is very much understood by many people. You could always point somebody out to get him-/herself some documentation and teach himself. MVC is kind of easy to grasp and to grow.
For me it is very important to get down to the beef early. It is not an option to start teaching OO upfront for a couple of weeks before the developers cut their first designs/code.
How do you make that happen or do you "just" work in small projects with only a few people?
Looking forward to your upcoming book on patterns.
Cheers,
Mariano from Germany
ps. Why do you use so "unusual" naming conventions, like with "_" etc.? That is another point which will never, ever integrate smoothly with existing code. Even if you start on a green field, there are always libraries or Java itself to interact with. So, even if you have thought out something which is 30% better, does it pay off, when it comes down to the real world?
|
Anonymous
Unregistered
|
|
Personally I find the concept of having the same business logic for different view platforms (e.g Swing vs HTML), a false hope. I've found the business logic is too strongly tied to the capabilities of the UI you are using. Either the code becomes too unwieldy or you compromise functionality. Alan Cooper warned against this approach in About Face in regards to developing a single code base for multiple platforms. (pre-java days)
From my experience, the whole point of "render thy self" is that some parts of the UI are intrinsically coupled to the data. You shouldn't try to artifically de-couple them. If you keep the data and UI that is directly affected by the data together, you can better control and manipulate those parts that are intrinsically tied together. Basically you make your code more cohesive. Examples of intrincally tied ui and data are things such as the viewability (hidden or viewable) or changeability (view only or changeable) of data. The trick is to keep the UI parts that are not dependent on the data outside of the business code. These are often things like formatting and stylistic attributes such as color, fonts, field placement, etc. You don't want nor should you have your page layout guy messing with code that affects logic. (e.g. in HTML keeping name values and href tags correct)
Paul L.
|
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
