>
> An approach like this is considered useful to tack down complexity if you
> have a very large and/or complicated business model. For example you can
> concentrate on writing business code in a Record class and have a
> RecordMapper class that hides the database and saves and load Record
> instances. However, mantaining a data mapper layer is a heavy work, so I
> have integrated Doctrine (an ORM) in my Zend Framework applications.
> Doctrine is not a real DataMapper (search for the pattern) because model
> objects are not database agnostic, it also has many static clings, but
> it's
> a useful tool.
>
Yes, my project is somewhat small and uncomplicated so to speak, but has
great opportunity for expansion and complexity down the road, hence why I
want to make sure I am on the right path now, so if/when the project
actually takes off, it can grow up to be a large enterprise application,
being managed and developed in a team environment with little growing pains.
Well it's good to have dreams and hopes, (laugh), either way, the project as
it stands could probably be hacked together with sloppy code (as pretty much
every similar script I have come across has been made, though the biggest
drawbacks to the *competition* so to speak is the lack of ability for growth
and difficulty of code modification without a lot headaches).
My goal to eliminate the problems I see in other similar applications
effectively with coding the application to be as dynamic as possible, and to
incorporate proper unit testing and best coding practices.
In regards to the RecordMapper / DataMapper, yes, simple, I have a pretty
good understanding of the concept behind that design pattern. From the
simplest of explanations I put in place business logic that links one to
one/one to many/many to many relationships between tables, through
inner/outer joins, and on deletes and stuff. I think it missed explaining
myself, as I am not so much looking for the ORM side of things as I am
looking for the logical side of things.
Let me clarify with a skeleton code of one piece of my puzzle.
The Model:
<code>
class Forge_Zipcode
{
private $_data = array();
private $_dataSource; // This can be one of multiple sources
public function __construct()
{
// Handles the initial setup of the model (default settings)
}
public function __destruct()
{
// Handle any shutdown functionality (writing changes if
necessary/allowed)
}
public function __set($property, $value)
{
if (in_array($key,
array('zipcode','latitude','longitude','city','state','country'))) {
// handle specific filtering and validation here.
$this->_data[$key] = $value;
} else {
throw new Forge_Zipcode_Exception("Invalid property, unable to
set [$key]");
}
}
public function __get($property)
{
// Bet you can't guess what code I am going to put here!
}
public function setDataSource($source)
{
// Set the data source in private property $_dataSource
}
public function load($zipcode)
{
// Generic code to load a specific record from the data source
provided (all data
// source adapters would inherit a specific contract / set of
methods and properties)
}
}
</code>
Now as you can see, this is somewhat inconsistent with a pure OO model. So
what I am *thinking* is that I should have something like the following:
<code>
class Forge_DataType_Zipcode; (which would merely be a set of
validation/filter/transformation methods along with specific properties of
the data type ie city, state, longitude, latitude etc)
class Forge_DataSource_MySQLTable (extending the functionality of
Zend_Db_Table_Abstract) for access to a MySQL table
class Forge_DataSource_CustomTable (custom functionality for another
database type)
class
Forge_Module_SomeBusinessProcessThatRequiresZipcodeLoadingManipulatingAndSaving
(of course a portion within say a controller or specific point in the
application that contains business logic)
</code>
so what we have here is something like :
Controller -> Model -> DataMapper -> DataSource
Now I have also read about wanting to break this down further to have a
'thin' controller, *so* my question is how can I make the above code to be
more 'pure OO' compliant, what am I missing between the controller and
model, and can someone give me some basics on including unit testing. Is
there some good web resources for helping put this all into perspective for
me.
I am currently working my way through "Domain Driven Design by Eric Evans"
and "Patterns of Enterprise Application Architecture by Martin Fowler" both
of which have been recommended in other threads on similar topics. I
actually picked up the PeEAA a quite a while ago and only glanced through it
and shelved it. I have dusted it off now and am going through it :)
I haven't come across any good books / websites on unit testing yet (but it
has only recently become an interest, so I haven't searched very far for
information).
The above code is very cut down from what I actually have it doing, but I
would love to hear recommendations of better modeling. And maybe
suggestions on the namespacing as well, I am keeping it compatible with
Zend_Loader::registerAutoload(), partially for organization purposes, but
mostly because I find require/include statements very annoying (laugh) -
hated it so much that I built my own autoloader class back in the early days
of php 5 actually, have avoided require/includes in my code ever since (of
course besides the autoloader class file itself, sigh, still working on
getting out of that one too heh.
Anyhow, rambled on long enough here, hope that clarifies what I was / am
looking for,
Thanks
Aaron
--
View this message in context: http://www.nabble.com/Pure-Domain-OO-Modelling-tp20949169p20962776.html
Sent from the Zend MVC mailing list archive at Nabble.com.
没有评论:
发表评论