User – Member Class Design In Mvc

[Antonio Conte]

Hey, YII developers.

 

This is not related to YII per-say, but It's pretty close.

 

I'm working on a system that requires authentication (A User). We however also need the type type of Member. The User will take care of login/logout, access_levels, etc. The member will hold membership data on a per-season basis, as payments are made for membership. The members should then be able to edit personal information like address, email, phone number, etc. (But not anything really vital should someone crack into our database)

 

Important: The User should also be usable in the system without being a Member. (Because the User is needed for other things in the backend too)

 

I'm wondering how you would solve this in Yii? I've thought about:

- Extending. Member extends User

- Composition. The User object holds a Member object.

 

These are class skeletons for User and Member:

 

Edit: See new post instead.

 

Class design:

I'm also wondering if you'd split this into several classes?

- Would you create both a fully function User class and a User model, our would you make a thick model that handles everything? The question also applies to Members.

- If you create both classes and models, would you combine the Model anyway?

 

How would you go about designing the classes here? Hoping for some input.

 

I'm not yet very experienced working inside an MVC pattern, and as this pretty much lies the fundation for our project, we NEED this done correctly.

 

Alternative approaches are also welcomed.

 

Wishing for private classes in PHP like in Java, btw...

[Antonio Conte]

Ok. I've started to build a solutions where a Member object can be attached and detached from the User object.

[Antonio Conte]

Ok. Very little input on this. We decided on a solution.

 

I'm sharing it here in case anyone faces a similar problem. It's more of an interface than 'ready to use good', but it illustrates the hierarchy. The User class will become part of our core classes, while Model_User takes care of interacting with the DB and returning User/Member data.

 

<?php

/**
* User class
*/

class User
{

   /**
   * Login
   *
   * @param String $username
   * @param String $password
   * @return boolean
   */

   public function login ( $username, $password ) { }

   /**
   * logout
   *
   * @return void
   */

   public function logout ( ) { }

   /**
   * is_logged_in
   *
   * @return boolean
   */

   public function is_logged_in ( ) { }

   /**
   * has_access
   *
   * @param int $access_level The needed access level
   * @return boolean
   */

   public function has_access ( $access_level ) { }

}

/**
* User model
*/

class Model_User extends Model
{

   /**
   * get
   * Will return an array of user and member data if the user id exists.
   * If not, a null value will be returned.
   *
   * @param int $user_id The user id of a user
   * @return array|null A User/member array on success, else null
   */

   public function get ($user_id)
   {
       // get user data....

       // $this->get_member($user_id);
   }

   /**
   * register
   * Will insert a new row into the User table with user data
   *
   * @param Array $data
   * @return True on registration, else false
   */
   public function register (array $data) { }

   /**
   * modify
   * Will modify an existing user
   *
   * @param Int $user_id
   * @return boolean True if modified, else false
   */

   public function modify ($user_id, array $data) { }

   /**
   * get_member
   * Will get the member data for the specified user id if it exists.
   *
   * @see Relies on Model_User::has_member
   * @return array|null Array if member is found, else null
   */

   public function get_member ($user_id) { }

   /**
   * is_member
   * Will return true if the user_id has a member_id set in the DB
   *
   * @return boolean
   */
   private function is_member ($user_id) { }

}

[Larry]

Sorry, Thomas, this one slipped by me. Still need any input on it?

[Antonio Conte]

If you have suggestions, we would definitely like them.

[Edward]

With Yii you don't have to bother with all those classes, you can extend or override their one's, that was the point of the framework.

 

I think its probably better starting of with codeigniter php framework, most people are saying that if you want to learn MVC its best to start here then move to Yii later which is off course much better.

 

Coding seems to be the easy part of web development, css seems to me to be the MF of it all.

[Larry]

Okay, finally read through this in detail. I agree that Composition doesn't sound quite right here. Your solution seems okay, but I'm wondering if there's something better. Just to confirm, not all users will be members but all members will be users? And there's only at most a one-to-one relationship between users and members?

[Antonio Conte]

Sorry. English is not my first language. Sometimes I mix up words. Object Aggregation is more what I should describe what I'm thinking.

 

A User handles authentication to the system, access levels, and other privileges. Each Member must have a User. The Member is not an extended version of the User. This is because the User should be able to continue to function and exist even if we remove the Member data associated with it. Being a Member, in our setting, does not affect access levels or other privileges. They will only allow you to edit personal information and apply for match tickets.

 

In part, they are both valid entities. In our setup though - a Member cannot exist without a User. The Member makes no sense alone, as login (aka a User) is required for changing personal Member data. Should a User decide not to be a Member, other parts of the system should still be available to them.

 

Taking all this info into account, (hope you makes sense of it) do you feel I'm correct when I want Member data as an aggregation to the User object?

 

Aggregation (...) implies encapsulation (hidding) of the parts of the composition. We can aggregate classes by using a (static) inner class (PHP does not yet support inner classes), in this case the aggregated class definition is not accessible, except through the class that contains it. The aggregation of instances (object aggregation) involves the dynamic creation of subobjects inside an object, in the process, expanding the properties and methods of that object.

 

Object aggregation is a natural way of representing a whole-part relationship, (for example, molecules are aggregates of atoms), or can be used to obtain an effect equivalent to multiple inheritance, without having to permanently bind a subclass to two or more parent classes and their interfaces. In fact object aggregation can be more flexible, in which we can select what methods or properties to "inherit" in the aggregated object.

 

If this was Java, I would definitely go for a static private inner class.

 

Does that sound right to you?

[Larry]

That does sound right to me, although as you well know, sometimes when these things get implemented, it turns out not to be right. But that's how I would move forward with this to see.