Just thinking through the refactoring and... idunno...
-
User Class/Object
- What is the user responsible for? Their roles & permissions (essentially, a user has to provide credentials in order to prove the access they have to something.). Logging in, maybe. Registering, maybe. Profile data.
-
Database Class / Object
- Responsible for all database operations across all tables. As the amount of functions grows to be hard to manage, the database class might be separated into multiple classes or multiple traits
-
Core Component
- Provides an API for working with the broader user system. a website developer will call the api functions to do everything they need. On some occasions, the site developer might call upon other classes directly, but it's not supposed to. The only things to expose to the site dev is the instantiated user object (after retrieving from this component), and the apis written in this component
It might help to think about all the things that the user app does. So:
- Register New Users
- Login new users
- Reset password
What are my primary goals with the refactor?
- Decouple Sentinel from my app - SIMPLY create a standin for Sentinel functions, so that I can do 1-to-1 replacements in a single class when I decide to drop sentinel.
- Replace the reference to the 'sentinel' object in the user class
- But not necessarily remove the reference to a database object
- Define a logical structure that is easy to maintain
- Separate major functional pieces of the user app.
What is NOT a goal of the refactor?
- Defining a class for every table in the database
- Replace Sentinel completely
- Decouple everything from each other
- Create the "perfect" architecture
- Turn the user class into a db-connected model
- Add functionality to the user class
- Add roles & permissions to the app
- Add features like replacing public files & views to the app.