Originally posted by Matt Kidd:
I'm trying to learn patterns by myself which in my opinion is a daunting task in itself. I have a few programs that I intend to build but I'm not sure if I've chosen the right pattern or how to implement it since I'm still at the level of where does the main go (I know a program can have multiple mains) when I worked on a project that used MVC.
The first is a simple scientific calculator. Think calculator within a windows system. How can I apply MVC to this? I undestand the view would be what the user sees, the model would be the actual computation, but the controller I get lost on.
Originally posted by Udayan Patel:
Calculator doesn't have model.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
That's not true. If you do MVC with a calculator, the Model likely will contain the current result and methods to to calculations on it.
The Controller will handle user input - react to button and key presses, and translates them into method calls on the Model and the View.
The View simply shows the current state of the model and the input gadgets (which the Controller reacts to).
Does that help?
Originally posted by Udayan Patel:
Technically speaking your model is your database. ... but Hey thats just me.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
Definitely that's you, yes.
Seriously, the Model is *not* the database. The Model "is" the business logic. The database typically is separated from the Model by a persistence layer.
And "a bunch of static methods"? Hell, this is the *OO* forum...
Originally posted by Udayan Patel:
hummmmm have I been smoking something all these years? I don't think so.
Model IS your database.
now your object Person or Employee or Customer thats what i call model, presents you with a face of database.
Originally posted by Adeel Ansari:
We can say Person or Employee or Customer as business entities, not the M of MVC.
thanks
[ December 13, 2004: Message edited by: Adeel Ansari ]
Originally posted by Adeel Ansari:
Model-view-controller:
Consider an application that needs to support multiple client types like WAP clients, browser-based clients, and so on. If we use a single controlling component to interact with the user, manage business processing, and manage the database,.......... I think its better not to talk about the database at all while discussing MVC.
it affects the flexibility of the system. Whenever support for a new type of view needs to be added, the whole application will need to be redesigned. Also the business logic will need to be replicated for each client type.
]
As a solution to this problem, the model-view-controller (MVC) architecture divides applications into three layers -- model, view, and controller -- and decouples their respective responsibilities.
The model represents business data and operations that manage the business data.
Originally posted by Udayan Patel:
Model IS your database.
Now thats what we call business logic. should be operating on data, and should not hold any data. thats what you call business logic. now your object Person or Employee or Customer thats what i call model, presents you with a face of database.
BTW when you speak of persistence layer that prepares model for your middleware(business logic) persistence layer does not sit between your model and database it sits between your domain model and middleware.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
Well, the business logic might run in some middleware, but that's certainly not obligatory. But if it does, I'd say that your domain model sits in the middleware.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
where in your idea middleware fits? To be little more explainatory, when I say middleware includes you EJB, RMI or someother type of implimetation of business logic.
Originally posted by Adeel Ansari:
Udayan,
And why I said Employee, Personnel, etc are the business entities. because we map these Database entities by using Entity beans or someother API. if it confused you then you can say it as DB entities, no problem at all.
repeating the Ilja's words. Seriously, the Database is not the Model of MVC, nor the persistence layer.
cheers
[ December 13, 2004: Message edited by: Adeel Ansari ]
Cheers, Sathya Srinivasan - SCJP 1.2, SCWCD 1.2, SCMAD 1.0
Co-Author of Whizlabs SCMAD Certification Exam Simulator and SCMAD Exam Guide Book
Originally posted by Sathya Srinivasan:
Hmmm... I snooze for a few days, wake up, and find myself in the middle of a nightmare!
If a model is a database, then do you imply that system such as peer-to-peer networks which do not technically have any persistance do not have any models?
Persistance is more of an after-thought rather than something integrated into the system. A system should not be built relying on persistance or a specfic type of persistance (read database).
What has DAO taught you?
Even if you look at the DDD book by Eric Evans, he purely describes about a business object model with one chapter or repositories. The idea is that the model is a representation of the problem in a business domain. It is optional (although almost always happens) that the whole thing is persisted. Even in Java, you implement Serializable optionally if you want to persist the object.
Back to the Calculator.
I think Ilja nailed it with his statement at the beginning.
1. The buttons on the calculator is your view. You can have different types of views - say, big calculator, paper-thin calculator, watch calculator, etc. In some cases, it can even be a Web Service that other applications can invoke.
2. The actions that initiate the calculation would be your controller. This can be an ActionEvent from your buttons or a web service call. This would be a standard API that would be exposed by A scientific calculator (Facade?).
3. The stuff that actually does the calculation would be your model. I could probably think of the number system as the model. For example, I can break the calculations into arithmetic, trigonometric, calculus, etc.
For a calculator, I really don't see any need for persistance (except maybe for some lookup tables). Calculator is by definition, a stateless machine. If a machine is stateless, then why need a mechanism to store the state of a system?
Originally posted by Udayan Patel:
I would not make a mistake comparing business application v/s technology applications. Orange v/s apple (transactional system v/s non-transactional)
so, lets say you have classes called Arithmatic, Trigonometry and such. I am sure you wouldn't permit your basic object Number to have Number.add(to) or Number.substract(from) on them
you would rather have your Arithmatic class take care of it. And it makes sense perfactly.
The point is though what would you call Number and what would you call Arithmatic? are they both part of your "model"?
Arithmatic as part of your middleware?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Sathya Srinivasan:
For a calculator, I really don't see any need for persistance (except maybe for some lookup tables). Calculator is by definition, a stateless machine.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
You seem to be using an unusual definition of middleware. For me, middleware is something I use, like an RMI implementation, not something I create.
See http://en.wikipedia.org/wiki/Middleware
Originally posted by Ilja Preuss:
That's not true. If you do MVC with a calculator, the Model likely will contain the current result and methods to to calculations on it.
The Controller will handle user input - react to button and key presses, and translates them into method calls on the Model and the View.
The View simply shows the current state of the model and the input gadgets (which the Controller reacts to).
Does that help?
Originally posted by Sathya Srinivasan:
Back to the Calculator.
I think Ilja nailed it with his statement at the beginning.
1. The buttons on the calculator is your view. You can have different types of views - say, big calculator, paper-thin calculator, watch calculator, etc. In some cases, it can even be a Web Service that other applications can invoke.
2. The actions that initiate the calculation would be your controller. This can be an ActionEvent from your buttons or a web service call. This would be a standard API that would be exposed by A scientific calculator (Facade?).
3. The stuff that actually does the calculation would be your model. I could probably think of the number system as the model. For example, I can break the calculations into arithmetic, trigonometric, calculus, etc.
For a calculator, I really don't see any need for persistance (except maybe for some lookup tables). Calculator is by definition, a stateless machine. If a machine is stateless, then why need a mechanism to store the state of a system?[/QB]
Originally posted by Ilja Preuss:
Well, I think it needed to at least remember the current result - not really stateless...
And than it could have those nifty "M+", "MR", "MC" buttons, etc.
To avoid criticism do nothing, say nothing, be nothing. -Elbert Hubbard. Please critique this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|