I have been programming in PHP for several years and have in the past adopted methods of my own to handle data within my applications.
I have built my own MVC in the past and have a reasonable understanding of OOP within php but I know my implementation needs some serious work.
In the past I have used an is-a relationship between a model and a database table. I now know after doing some research that this is not really the best way forward. As far as I understand it I should create models that don't really care about the underlying database (or whatever storage mechanism is to be used) but only care about their actions and their data.
From this I have established that I can create models of lets say for example a Person an this person object could have some Children (human children) that are also Person objects held in an array (with addPerson and removePerson methods, accepting a Person object).
I could then create a PersonMapper that I could use to get a Person with a specific 'id', or to save a Person.
This could then lookup the relationship data in a lookup table and create the associated child objects for the Person that has been requested (if there are any) and likewise save the data in the lookup table on the save command.
This is now pushing the limits to my knowledge.....
What if I wanted to model a building with different levels and different rooms within those levels? What if I wanted to place some items in those rooms?
Would I create a class for building, level, room and item
with the following structure.
building can have 1 or many level objects held in an array level can have 1 or many room objects held in an array room can have 1 or many item objects held in an array
and mappers for each class with higher level mappers using the child mappers to populate the arrays (either on request of the top level object or lazy load on request)
This seems to tightly couple the different objects albeit in one direction (ie. a floor does not need to be in a building but a building can have levels)
Is this the correct way to go about things?
Within the view I am wanting to show a building with an option to select a level and then show the level with an option to select a room etc.. but I may also want to show a tree like structure of items in the building and what level and room they are in.
I hope this makes sense. I am just struggling with the concept of nesting objects within each other when the general concept of oop seems to be to separate things.
If someone can help it would be really useful.
The building/level/room/item structure you described sounds perfectly fine to me. Domain-driven design is all about understanding your domain and then modeling the concepts as objects -- if you can describe what you want in simple words, you've already accomplished your task. When you're designing your domain, keep everything else (such as persistence) out of the picture and it'll become much simpler to keep track of things.
There's nothing wrong about that. Buildings in the real world do have floors, rooms etc. and you're simply modeling this fact.
In DDD terminology, these "mappers" are called "repositories". Also, your
Building
object might be considered an "aggregate" if it owns all the floors/rooms/items within it and if it doesn't make sense to load aRoom
by itself without the building. In that case, you would only need oneBuildingRepository
that can load the entire building tree. If you use any modern ORM library, it should automatically do all the mapping work for you (including loading child objects).Let's say you organize your objects like so:
In order to initialize the whole building object (with levels, rooms, items) you have to provide db layer classes to do the job. One way of fetching everything you need for the tree view of the building is:
(zoom the browser for better view)
Building will initialize itself with appropriate data depending on the mappers provided as arguments to initializeById method. This approach can also work when initializing levels and rooms. (Note: Reusing those initializeById methods when initializing the whole building will result in a lot of db queries, so I used a little results indexing trick and SQL IN opetator)
Now let's say we have this db schema
And finally some code.
Building
Level
Room
Item
If I understand your question right , your main problem is that you are not using abstract classes properly. Basically you should have different classes for each of your building, levels, rooms etc. For example you should have an abstract class Building, an abstract class Levels that is extended by Building and so on, depend on what you want to have exactly, and like that you have a tree building->level->room, but it's more like an double-linked list because each building has an array of level objects and each level has parent an building object. You should also use interfaces as many people ignore them and they will help you and your team a lot in the future.
Regarding building models on a more generic way the best way to do it in my opinion is to have a class that implements the same methods for each type of database or other store method you use. For example you have a mongo database and a mysql database, you will have a class for each of these and they will have methods like add, remove, update, push etc. To be sure that you don't do any mistakes and everything will work properly the best way to do this is to have an interface database that will store the methods and you will not end up using a mongo method somewhere where the mysql method is not defined. You can also define an abstract class for the common methods if they have any. Hope this will be helpful, cheers!