Insecure? Me? I thought that I was so secure in my beliefs (the belief that my methods are different, not necessarity better) that I was branded as arrogant! So now I'm insecure as well.Originally Posted by lastcraft
I guess I need therapy real bad
| SitePoint Sponsor |
Insecure? Me? I thought that I was so secure in my beliefs (the belief that my methods are different, not necessarity better) that I was branded as arrogant! So now I'm insecure as well.
Earlier I said I had some reservations about Tony's inplementation of the MVC pattern, and it's this sort of thing I have reservation about?From what I have seen so far your choice of shortcuts does the exact opposite. Having table names rippling upward will cause a maintanence headache.
From reading the posts in this thread the Presentation layer shoulldn't need to know of what fields to use from the database. Looking last night on Tony's site, I seen in XML he passes over the database field names (for whatever reason).
This isn't real seperation of concerns surely? A XSL stylesheet doesn't need to know this, all that it's interested in is getting the data from the XML and parsing it dependent on a given template, nothing more.
Tony, why do you need the ID attribute?Code:<root> ...... <structure> <main id="person"> <columns> <column width="150"/> <column width="*"/> </columns> <fieldlist> <field id="person_id" label="ID"/> <field id="first_name" label="First Name"/> <field id="last_name" label="Last Name"/> <field id="initials" label="Initials"/> <field id="nat_ins_no" label="Nat. Ins. No."/> <field id="pers_type_id" label="Person Type"/> <field id="star_sign" label="Star Sign"/> <field id="email_addr" label="E-mail"/> <field id="value1" label="Value 1"/> <field id="value2" label="Value 2"/> <field id="start_date" label="Start Date"/> <field id="end_date" label="End Date"/> <field id="selected" label="Selected"/> </fieldlist> </main> </structure> </root>
The above snippet of XML is describing domain data whereas it shouldn't as I see it? Maybe some one can clear this up for meCode:... ... <field id="person_id" label="ID"/> <field id="first_name" label="First Name"/> <field id="last_name" label="Last Name"/> <field id="initials" label="Initials"/> <field id="nat_ins_no" label="Nat. Ins. No."/> <field id="pers_type_id" label="Person Type"/> <field id="star_sign" label="Star Sign"/> ... ...
Our 'rules' as you put it are design patterns and proper OO Programming. The bulk of members who frequent this very forum I guess are aiming towards those design patterns and OO Programming methodologies.Every one else wants me to change my code so that it operates according to their rules, and as I see no benefit in these rules I regard them as destructive and choose to ignore them.
If you do not understand the importance of design patterns and just what they actually mean to todays developer then you need to start to learn them before you saying anything more.
Lastcraft, Harry, Selkirk, SweatJs, amonnst many others practice good OO analysis and design everyday, thankfully they take the time out to help others learn better (and do note that word) and more.
For you to turn around and say that your methods are better is shear ignorance. You say on your web site you understand deisng patterns? Apart from the MVC pattern (your implementation that is) what other patterns have you implemented thus far?
I'd be interested in knowing that. I have a lot more to say but I'm not going to as basically this is a sociable forum, and what I have to say isn't really soaciable
Just some remarks:
Encapsulation is a word, it is well defined and I think one of Tony's document (the .txt one) talk about this. One of the mean in OOP of Encapsulation is only the propriety to encapsulate stuff into something. Oohh... what mean Encapsulate? Dictionary.com:
"To encase in or as if in a capsule."
That is. Nothing more, nothing less. We could probably say a simple function also encapsulate. We can also say class should get method and not function (different word, but in the way they are defined in php, it means what it is defined to be).
Why those functions; classes; packages/namespaces; folder; files? Encapsulate. Why an Earth? another Capsule.
How you decide to encapsulate is your choice with its advantage and disadvantage.
---
Secondly a pattern is a pattern. Sure there is some rule that has been accepted like we give it a name, example, etc. However a pattern is a pattern and it has been named that way because it is a pattern, repeating the same pattern as my first comment, heading to dictionnary.com:
http://dictionary.reference.com/search?q=pattern
Interesting definition of it (going fast):
"A model or original used as an archetype. " -- that is when you use one for yourself.
"A consistent, characteristic form, style, or method" -- that is when people often do the same way.
People have labelled Tony's way as Table Data Gateway, etc. I cannot say it is true or not. But let's say it is very similar or is the Table Data Gateway pattern... then that he read or copied Martin Fowler's writting is irrevelant, what he did was that. You think some people have never done the Singleton before hearding the pattern? You think nobody found intelligent way to do a database/business mapping before and that it does not look with the know pattern of today? Well, it has become a pattern and it has been solved that way since long.
---
I'm also sure there is good OOP dictionary outta there. Design common accepted term and language construct is different thing. We can use the same word, which mean the same thing to different domain of application and they won't be 100% the same thing. i.e. one word in language construct and the same word in design, and the same word within your baseball team. They will have a similar abstract meaning (if used logically) but a different concret meaning.
---
Enough babbling... ;-)
The XSL stylesheet does not know which fields are connect to the database and which are not. It does not know which fields are in which table. It is just given a list of element names and their values. Each row is given a group name which just happens to be the same as a table name. I keep the names the same as there is no logical reason why I should invent different ones.
As for 'separation of concerns' your interpreation of what that means is confusing. The model is reponsible for obtaining data which may either be from the database or through calculation. The model does not generate any XHTML as that is the concern of the XSL stylesheet. The XSL stylesheet gets its data from the XML file, but it does not care a jot where it came from or how it was contained. It simply takes the contents of the XML file and transforms it into XHTML.
To me the separation of concerns is quite clear:
- The model obtains data but does not convert it into XHTML.
- The XSL stylesheet converts the data into XHTML but does not obtain it.
- The only connection between the two is an XML file which contains elements, data and attributes.
How would it be possible to have a greater 'separation of concerns'?
Rather than have the element (field) names hardcoded within the XSL stylesheet, which would therefore require a separate stylesheet for each screen, I include a list of element (field) names in the XML data. This identifies which elements are to be extracted from the XML data, in which order, and what the associated label should be.
In this way I have a small set of generic stylesheets which can be used for any number of different screens. Hows THAT for reusability?
It is describing which elements are to be extracted from the remaining XML data in order to construct the XHTML output. What on earth is wrong with that? An XSL stylesheet cannot function if you do not tell it which elements to deal with.
Nothing as such some may think but it does mean having to change the XML file to suit the database schemaWhat on earth is wrong with that?
What I would have done was to wrap the data in commonly names tags, ie
This is the way I've done so in the past. Now why would I need a separate stylesheet, where all output generated is to be of the row/column format? That's the point I'm trying to get atCode:<row> <cell>some data here</cell></row>
The stylesheet in question shouldn't need to know what the data is or what format it is, nor what order to display it as, it just transforms the data nothing more, yes?
Your 'rules' are simply your version of what is 'proper'. I have been a software developer for two decades, and without exception every team that I have joined has had its own set of 'rules' which described what it thought was 'proper'. There is no such thing as a single set of 'rules' which everybody must obey.
The fact that so many people seem to follow these rules just means that they are followers, not leaders. Do they follow them beacuse they are the best rules, or because they are afraid to rock the boat? Do they follow them because they have experienced other rules which have proved to be inferior, or because they are told to?
There is only one set of rules that I have no option but to obey (and which does not give me a problem) and that is:-
- The rules of the development language, e.g. PHP, XSLT.
- The rules of the database engine.
- The rules of the HTTP protocol.
- The rules of the user interface, e.g. XHTML and CSS.
Everything else is down to personal ingenuity and skill, and I demand the right to exercise that ingenuity and skill in whatever way I see fit, and without being restricted by your artificial rules.
I have been using patterns for many years now, so I understand their importance. However, the patterns I use have been gained from personal experience, not read from a book. Some of the ways that I design and build code may be described in books of patterns, but I do not recognise the name and rarely recognise the description.
I have never claimed that my methods are better than all other methods, just different.
The Singleton. I have looked at some others, like the Front Controller, but I can't find a use for them.
Unlike some people I do not implement patterns because they are 'cool'. A pattern is a solution to a problem, and if I don't have that problem then why do I need that solution?
I would never have guessed.
The XML file is generated automatically from whatever data the model provides it with. Plus, of course, a list of element names to process. There is no connection with the database schema.Nothing as such some may think but it does mean having to change the XML file to suit the database schema.
No. The XML file may contain data from multiple occurrences from multiple tables, so it makes sense to give each row the table name rather than just 'row'. Why? Otherwise the XSL stylesheet may get confused as to which 'row' you meant.
It also makes sense to give each column a unique name (such as the corresponding field name) instead of just 'cell'. Why? Because you may want to extract and process the column details in a particular order, not just the order in which they appear in the XML file. The beauty of an XSL stylesheet is that it does not matter one little bit about the order in which the data was written to the XML file, so the order in which data is written to the XHTML output is controlled by the sequencing of XSL statements.
And yes, the XSL stylesheet DOES need to know what the data is and how to format it, otherwise it will not know which HTML control to use. Is the field display only? Does it need a text box, and if so, what size? Is it a dropdown list? Is it a radio group? Is it a checkbox? The XSL stylesheet needs to be instructed on what data to display, where and how, and also what label to give it.
From your comments it would appear that you have absolutely no knowledge of how XSL stylesheets work, especially in the way that I use them, so your theories on how they SHOULD work are not constructive at all.
Hi...
Interesting. I hadn't thought about splitting them up until now, as in practice I do find them synonymous. I am still thinking about this but, as devil's advocate, how does dependency differ from visibility?
yours, Marcus
Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
I look at dependency as how much one class relies on another to do it's job. On the other hand, I look at visibility as to the classes that are accessible from within a particular class.
JT
So, if you had code like:
Would you then say the View depends on the Model (for the results of the getData method) but has no visibility (because the results of the method are passed, but not the object itself)?PHP Code:class controller {
function run() {
$m = new Model;
$v = new View;
$v->assignData($m->getData());
$v->display();
}
}
Whereas the controler depends on both (to sucessfully run() ) and has visibility to both (because it creates them)?
Jason Sweat ZCE - jsweat_php@yahoo.com
Book: PHP Patterns
Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
Detestable (adjective): software that isn't testable.
Hi...
Ah, the holy grail...
This is a criticism often levelled by the Relational people against the OO'ers. There is no exact definition of OO as you say. Using language constructs as definitions doesn't work, because how do you then decide if a language is OO? It becomes a tautology. This means that what is or is not "OO" is described pretty much by the community itself. Note that there is actually a pretty much agreed "thing" out there, not lot's of variations as has been implied. It can take some finding, but it is there.
There are two sources of confusion here I think...
A description of a horse by a bookmaker would be different to a description of a horse by an anatomist. They are describing the same thing, but their descriptions out of context can sound contradictory.
The other source of confusion is change over time. The distinction of OO'ness has become stronger over the years. The original notion of encapsulation was born of "modules" in an earlier time. Early eighties people thought that we would get code reuse from inheritance and we would have configurable components that would have their knobs twiddled behind the scenes. Encapsulation is easy to define in terms of modules and configuration. We would sell reuasable components. What a wonderful world it was going to be.
Well that didn't work out so well. Inheritance turned out to be a pain (breaking encapsulation as they say) and twiddling behind the scenes causes surprises and is difficult to make explicit. Inheritance gave way to the rise of polymorphism and with it the birth of patterns. Configuration gave way to generative programming to push it back into the explicit source code realm, as well as polymorphism again.
Because we had opened up those modules for change within the code again, we have to revisit encapsulation and look at what we were trying to achieve from it. The result is that we do now have a tighter definition for OO. It's called the Open-Closed principle. Does it contradict the notion of "encapsulation"? Not at all. In fact it puts that concept more sharply into focus.
The march of OO continues. Generative techniques are now distinct. When Java 1.5 got generics I don't think anyone thought of it as "more OO". We now also have other "encapsulation" breakers such as Delegates and Aspects. This is not a theoretical exercise, but a pragmatic search for what parts of our code we want to hide, and what parts we may need to extract. It's all built on community experience and "best practice" and defined in terms of the current shared vision. Not ideal, but that's the way it seems to be.
There were some research programs to put OO on a more secure foundation. The Funnel langauge for example aims to be an OO language built on top of a functional one. I don't know if they discovered anything important, but if they have it doesn't seem to have re-entered the community.
We live in interesting times as the Chinese would say
yours, Marcus
Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
We live in interesting times as the Chinese would sayOff Topic:
Sorry for the off topic interjection, but I did a little research on that quote earlier this summer and found this link: http://www.noblenet.org/reference/inter.htm
This is interesting. I'm assuming that Fowler's use of the phrase "call from the domain or data source" (my emphasis) means that the function call is in the presentation code but the function is specified in one of the other tiers.
Would you say, dagfinn, that a templating system which "pulls" data in by with something like <?php $anObjectinAnotherLayer->oneOfItsMethods() ?> violates this principle?
Hi...
I was very careful to place the word "force" in my explanations for this very reason.
God? Now there is an interesting one. What is a god? An expert? A guru?
My style of coding is actually very different from Martin Fowler's. I am very much in the behavoural camp compared with Mr. Fowlers more structural style. I disagree with his naming conventions for example in his enterprise patterns book, so hardly a God. I'll still read the book however.
I consider what he writes worthy of my interest. Does that make him an "expert"? I think that is a fair description, although I doubt he would use that himself. It's not a very useful word, because it's not expertise that adequately describes what makes a great book or article. It comes down to this fuzzy concept of depth of understanding. If I constantly have my eyes opened to a new way of looking at things by someone, I will search out more of their material. I want to be challenged in my thinking by someone who has been there before. I want a possible next step up the ladder.
How do I spot people who are similarily interesting? By the same mechanism really. I look for people who delight in having their own views challenged. People who actively search out knowledge, people who discuss half formed ideas in the hope of finishing them and people who are enthusiastic about other's discoveries. Easy really?
From the parts that have been posted and the bits I ended up being dragged into looking at.
Truce?
I have to ask, what is the purpose of your article? Why are you posting here? I really do mean on a personal level. What part of it do you enjoy? Perhaps there is another way of continuing this discussion so that we both actually benefit.
I give you credit for your efforts at documenting your first architecture, as it's very worthy and few others put aside that much time. Why not let it stand on it's own merit in your "article" and dump all of the opinionated junk? Why not try reading the Fowler book? It means that you could more accurately describe your library to others. If you smoothed out the rough edges there might be parts usable in there by others as well.
I don't think anyone has suggested making major changes. Your set up is a solution and there may be others out there with the same problem. Some self defeating parts could be tidied up and you might end up with a more flexible library with wider applicability.
yours, Marcus
Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
First a disclaimer: as you may be aware of given the number of OO-related posts I made here, I am an OO proponent, I'm just trying to be not a blind proponent. Ok, that's the disclaimer.
You are right that it's a criticism by relational people (I assume you're referring to Fabian Pascal here). I have to admit I am rehashing his arguments here. And that is because I believe there is truth in them.This is a criticism often levelled by the Relational people against the OO'ers.
When you think about encapsulation, it makes sense not to directly expose an object's properties, but to 'encapsulate' them behind getters and setters: the most commonly heard argument for this practice is that if you change property x from a linked list to an array, all code that directly accesses property x breaks. Put it behind a method and it won't. Makes perfect sense: separation of interface from implementation.
However, when you think about encapsulation of data related to data storage (which is what this thread is about in part), encapsulation is in conflict with that other OO principle, what's it called, coupling. The methods are coupled to the data while you need to store only the data in a database and you need to go through a lot of trouble to get the data out through the methods. And as we all know strong coupling is bad
Ok, if you are convinced that you need to hide code, delegates and aspects may be a good thing.We now also have other "encapsulation" breakers such as Delegates and Aspects. This is not a theoretical exercise, but a pragmatic search for what parts of our code we want to hide, and what parts we may need to extract.
So it's built on community experience with those modules and other things you talked about, right? Ok, if for the sake of argument we restrict ourself to doing OOP in its current form (as you said it has been changing over the years, been refined if you prefer that), all of those best practices are perfectly valid, you won't hear me deny that. But who says that OOP is the best choice there is?It's all built on community experience and "best practice" and defined in terms of the current shared vision. Not ideal, but that's the way it seems to be.
Here's an analogy: you give me a screwdriver and I come up with all sorts of "best practices" on how to pound nails with that screwdriver or even how to cut wood with it, when I would be much better of using a hammer and saw, respectively. In this case the best practices are based on the wrong tool. So back to OO, I'm sure we have good best practices but is it the right tool for the job / all jobs (like data storage)?
Then you'll be delighted to hear that I have gone from total OOP proponent to OOP critic and dare to challenge other proponents
It seems quite clear to me. The presentation layer may call upon the business layer (or domain), the business layer may call upon the data layer, but neither the business layer nor the data layer may call upon the presentation layer, and the presentation layer may not call upon the data layer.This is interesting. I'm assuming that Fowler's use of the phrase "call from the domain or data source" (my emphasis) means that the function call is in the presentation code but the function is specified in one of the other tiers.
Would you say that a templating system which "pulls" data in by with something like <?php $anObjectinAnotherLayer->oneOfItsMethods() ?> violates this principle?
Hi...
I don't think OO is suitable for data storage per se and yes I do personally agree with a lot of Fabian Pascals comments (not all from what I remember). To me the biggest contradiction is that data storage is fundamentally about being able to query without being restricted by storage details. That means in effect everything being globallay accessable in some sense, which is hardly going to gel with encapsulation!
For building complex applications though, we need to be able to evolve them. That means we need the flexibility that encapsulation provides and we need the expressive power of objects or our tiny brains will never get anything right. So what we do is map across paradigms at the lowest level of the application.
Unless we hand code ActiveRecords or DataMappers there will be sacrifices. We don't usually want that, so we resort to tools and libraries. For the object model the first thing to go is usually inheritance on the data access classes. From the relational side we won't be able to provide the full range of joins and may have to load intermediate objects.
Basically the simpler the mapping layer, the more the paradigms are going to interfere and the more hand coding we will have to do when we run into a contradiction or performance issue. The only nasty situation is when we are using a database that has to be used by other applications. In other words we do not have control of the schema. Then I think you have to hand code.
It's only really coupled when that happens when we don't want it to. For example, let's say we decide to move a nullable field from one table to a joined in table instead. If a change like this affected anything above tha data access code then I would say it was coupled. If the most expedient way is just to add a required field all the way down, then it's irritating duplicated work, but I would say it's not coupled.The methods are coupled to the data while you need to store only the data in a database and you need to go through a lot of trouble to get the data out through the methods. And as we all know strong coupling is bad
Naked Objects is a reaction against this extra work. It defines a limited version of an object model, and requires full control of the database, but boy is it quick to add simple data fields. I don't think anyone would describe Naked Objects as a tiered app. though.
It may not be. Functional programming is great for doing data transformations, relational is great for organising and preserving data, Bayesian (Neural nets) is great for adaptive code, logic programming is great for complex business rules, full text is great for retrieving document content and OO is great for building enterprise applications.
OO is not so bad for glueing all this stuff together either.
Game onThen you'll be delighted to hear that I have gone from total OOP proponent to OOP critic and dare to challenge other proponents
yours, Marcus
Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
I agree. However, my infrastructure does not do that, so what makes you think that it does?I can asure you that my data passes through a 'formatting' function before it gets displayed to the user. This changes dates from 'CCYY-MM-DD' to 'DD-Mmm-CCYY', formats floating point numbers, and whatever else may be necessary.
I'm willing if you are. Just stop beating me around the head with all these books on design patterns as my poor delicate (big?) head is beginning to hurt.
I have been publishing articles on my personal website for several years now. The reason that I am posting here is because Harry Fuecks made a comment about my infrastrcture article in his PHP Blog. Among the postings was one from JNKlein asking about the separation between business logic and data logic. This generated such a large number of postings that JNKlein transferred the discussion from the blog to this forum. This is when the excrement hit the air conditioning and every man and his dog appeared to be queuing up to stick his knife into me.
Actually, this is my third. My first was in COBOL in 1985, my second was in UNIFACE in 1995, and now I've done it again with PHP. They say that practice makes perfect, so I'm well up on the practice part.
What's this? Praise? Good grief! I must lie down to get over the shock. Nurse! Fetch my medication!
Unfortunately it is in my nature to be blunt and opinionated. I just can't help calling a 'spade' a 'shovel' instead of a 'digging implement'
The trouble is that no matter what I do there will always be someone out there who will find some reason to criticise my approach. I have given up trying to please everybody else and concentrated on the task of producing software that pleases me with its simplicity, its elegance, its 'joie de vivre', its 'je ne sais quois'
I think that it is important that a developer be pleased with the fruits of his labours, that he take pride in it. I am (for my sins) both pleased and proud of my work as it contains far fewer problems than I have seen in the efforts of others.
It's late, and I can hardly keep my eys open, so it's up the wooden hill for me.
This is an exceptionally rich topic. A little more Wittgenstein and a little less angst? Possibly both Tony and lastcraft are right. OO embodies, AOT, a specialised form of conceptual graph (you might like:- Sowa J: Conceptual Structures - 1983 I think) which one would expect to be slightly degenerate in real implementations. I would hate to see a 'my version of the world beats yours' show and we can all try to sharpen the essential points of difference so that cleaner concepts emerge. We surely need them.
And, VersionO-OOe, that is how two brits might argue - you should see them play Rugby football. It is very easy to take their verbal methods for taking the high ground as arrogance but, as Webster's puts it, an arrogant person would be "exaggerating or disposed to exaggerate one's own worth or importance in an overbearing manner" which would engender in listeners "a feeling or an impression of superiority manifested in an overbearing manner or presumptuous claims" I think you might agree with me that it would be difficult to exaggerate the value of Tony's generous contribution and he has certainly made no presumptuous claims. Thanks for yours, too. I'll make my contribution after I have had time to kick the living **** out of the code.
Wow, there is a lot here. I have only skimmed, but I'd like to add a couple points. My apologies if I'm behind the times.
How did the term encapsulation get to be so controversial? Here is a good definition of encapsulation: Encapsulation is the grouping of related ideas into one unit, which can thereafter be referred to by a single name. This definition focuses on nameable things. In PHP thats functions and classes and files if you stretch it. Other languages have additional nameable grouping structures, such as Pascal's unit.
Why does water form a sphere in zero gravity? Because a sphere offers the smallest surface area for a given volume. Likewise, you should think of your units of encapsulation as spheres. They should expose the smallest surface area (interface) they can.
Robert Martin has a principle of OO design called the Interface Segregation Principle: Clients should not be forced to depend on stuff that they do not use.
The PHP 5 Interface structure is one method of exposing a smaller, more limited view of oneself to different clients, one interface for each role.
Another way to accomplish interface segregation is through delegation. A class can offer a different delegate object to each of its clients, depending on the role it is performing. With both methods, the size of the interface exposed to a client object is reduced and thus the potential for dependencies.
Robert Martin also has another principle called The single responsibility principle: There should never be more than one reason for a class to change. Each responsibility should be a separate class.
Signs that your unit of encapsulation (class|function) is too large:
- It is performing more than one responsibility or has more than one role.
- There are things its doing that its name would not suggest.
- It is hard to name.
As I understand visibility it's metaphorically an open door whereas dependency is what happens when you actually walk into the room.
You have visibility constraints such as private and protected methods and variables. In PHP 4, everything is visible in principle, but there's no dependency until you actually start accessing them.
Not having visibiliy between layers is difficult even in PHP 5, since there are no visibility restrictions on classes. Come to think of it, maybe you could use some clever include mechanism to do it.
That's how I understand it from the books I've read. (A largish percentage of them were your recommendations.
I read it as meaning that the call is in the domain or data source code, but I'm wondering if that's likely to happen in the real world. If you've done a reasonable job separating the code into layers, you're not likely to make that kind of mistake, I think.
This is interesting. A closely related question would be: do you pass a domain object into the template and let the template suck the information it needs from it, or does layering require you to make a separate presentation-related object (or a plain array) for the template to work with? I asked that question a few months ago in this forum, and I didn't get a lot of categorical answers.
I'm still not sure except I would definitely want to separate them if I didn't trust the people who were editing the templates. Especially if the domain objects had methods that might store data in the database (separate Data Mappers would avoid that, BTW).
"What if God was one of us, just a slob like one of us..."
As is usual this objective can be achieved in many different ways, and each person has his/her preferred method. In my own implementation of the MVC design pattern the controller sucks data out of the model and then gives it to the view. The idea of passing the domain object (model) to the template (view) in its entirety sounds very fishy to me. Surely the template would have to have knowledge of the internal structure of the domain object in order to extract the information it required? In my own case the process is simple because I made the decision to use XSL stylesheets as my view components. This requires the controller to suck data out of the model, convert it to an XML document which it can then give to the XLT stylesheet during the transformation process. In this way the view does not require any knowledge of the model. Indeed, an XML document is just a text file, so there is not even any knowledge of how it was created or what process created it.
This to me demonstrates a clear separation of logic. There is logic in the model which obtains data, and there is logic in the view which presents this data to the user via the user interface. The only connection between the two is the data. Although the data can change between one request and another, the logic remains the same.
Posting Permissions
Bookmarks