2

I'm busy developing the first phase of a hotel booking system based on a pure PHP MVC structure. I tried getting acquainted with the libraries like Cake and CodeIgniter but I wasn't comfortable with how little control I had.

So I opted to build my own mini framework which has worked out quite well for me so far. Now, the database structure I'm using is rather complex. There are quite a few many-to-many relationships and one-to-many relationships. I opted to not enforce any referential integrity in the database itself as I believe that should be done at a programming level to avoid frustration later on - things don't always work as planned and I find it easier to figure out what's going on programmatically than in an SQL database with less then explanatory error messages

SO, to the crux - the decision I'm struggling to make is where to place those arbitrary SQL statements to do with relationships between my different objects.

So, for example, I have two objects - users and properties. In this relationship, users are owners of properties that might house a room that will be rented out. In my Users object model (MVC) I have methods like 'insert', 'delete', 'update', 'getUser', 'userExists'. Similar methods exist in my properties model.

Each model extends a Database class that I created to leverage a connection to the database.

In this structure, where and how do I manage the relationships between these objects? The relationship is Properties_has_Users -> it's may-to-many. Where do I create the insert, update and delete methods for the relationship? In it's own object called "Properties_Users_Relationships? In the controller of one of the objects?

I'm new to these forums and in fact in my three years of development I've never posted on a forum - just read them so please let me know if there's something else you'd like me to post to reference or make it clearer.

Thanks

Kyle O'Brien
  • 932
  • 1
  • 11
  • 28
  • 1
    possible duplicate of [How should a model be structured in MVC?](http://stackoverflow.com/questions/5863870/how-should-a-model-be-structured-in-mvc). See the [awesome answer](http://stackoverflow.com/a/5864000/212940). Also you should [read this](http://pragprog.com/book/bksqla/sql-antipatterns). – vascowhite Nov 04 '12 at 10:37

1 Answers1

0

Wow, no offense, but you're making a mess. There is no true or false MVC, there is just MVC which is an architectual pattern and has nothing to do with a database. And php has enough good mvc frameworks, where you have plenty of control.

Anyway, you should have a Persistence layer which deals with everything storage including queries, table relationships etc. The business layer will have objects modelling the hotel booking process. The business object won't know about the database. It would be good to have a DAO or a Repository which will actually perfrom the queries and restore business objects.

It's important to model the business concepts ignoring the database concerns. Worry about the db when you have to save/load stuff.

For querying only, you can have a specialised Dao/repository which will hide the wueris and returns directly the view model for the views.

One of the important things to understand is that persistence model (what you save in db) is different than business model (the business concepts and processes). One is simply data, the other is behavior. The M is polymorphic, it can mean database structure or view data or the business behaviour.

Also perhaps this post will help you understand the M of MVC better.

MikeSW
  • 16,140
  • 3
  • 39
  • 53