The concept is fairly simple and helps me develop the component a great deal quicker than originally planned. I had originally planned to have a master DB object that handled all of the major features through a fluent interface. The point now, is that I want to do that, yes, but I want to simplify the code even more.
The problem before was that the scope was too great for me to develop and because it was massive, I had problem testing and seeing where the end was. I have difficulty programming like that. The way I like to problem is by building something that I can understand in my head. If I can’t understand how it all works, then I become depressed, because it is a great deal harder to see where you are out, if where you are going is off in the distance and over the horizon.
The solution now is to create the DB component in smaller chunks. In this way, I can improve the chucks over time and add new features by adding new chucks. There will of course, be problems with this solution, in that it will require refactoring in the future that may break backwards compatibility. I think of course, that to do so, will mean to increment the version. So everyone that uses version 1.x.x will always have compatibility with those versions. When new features are added, nothing will be removed that will break older versions.
Well, right now, version 1 hasn’t been released, so I feel as if I can do whatever I want. Just that I hope to get version 1 out the door sometime in a month or two, but most likely it will probably be sometime early next year.
DragonU DB Connection
The DB Connection object will have several parts and may rely on a config later on. The point is that when the config is added, it won’t require any work to be done to this object it will just rest on top of the DB components, so instead of building the DB connection objects manually as you will have to do when it is finished, you will have a configuration file that you can create the connections and manage them through that.
The purpose of this object is to store the PDO or PDO wrapper for MySQLi and MySQL extensions. The PDO Wrapper object will be developed later, however, the point is to allow PDO, since the API is standard and allows for many DBMS access through it. The PDO wrapper object will be an extra “feature” to allow for other extensions to work with the DB functionality.
After the PDO object or PDO wrapper Object is stored and connected, it will store that connection for the reminder of execution. So you can only have one connection per DB Connection object. If you need more than you need to create multiple DB Connection objects. However, the main library code will only use one DB Connection object for processing.
The code for this will be extremely simple. The connection can be created by either passing a PDO or PDO Wrapper object (it has its own method), passing a DSN string which will be used to create either a PDO (if the extension exists for the DB type) or PDO Wrapper object, or Resource or DB object for the ones that are supported. When the DB connection has been completed, the only other process is to pass the PDO object to the code base that will use it.
DragonU DB Connection Cluster
This works like the DragonU DB Connection object, but instead of passing the PDO object, it will instead pass itself which will in turn iterate certain calls to all DB connections. It will cycle through SELECT queries for each DB connection object in a dumb load balancing fashion.
The purpose of this container feature, is to use multiple connections for selecting and to keep all of the connections synced by passing queries to each of the connections. It makes more sense to use the DBMS cluster feature for most DBMS, but for some reason the feature in MySQL just plain sucks. Until they get it fixed, it will make a bit more sense to use this sort of emulation for the clustering, unless you have a lot of DB servers.
I could probably extend the feature set in the future, but I don’t want to get too far into what the DBMS does better. It is just a simple solution to what some DBMS makes more difficult and asinine than it needs to be. This is all it should be.
DragonU DB Main Component
This is the object that will manage take the DB Connection or DB Connection Cluster object and what other developers will work off of. It will be more of a factory than do any work and will be set up to allow for fluent interface usage. By keeping the main class stupid, it should be simple to add new features to it by what amounts to just “opening the door” to the feature.
DragonU DB Scheme Component
I’m still not exactly sure how I’m going to implement this. I think the simplest way is to create a loader which handles the inclusion of the scheme and passes the functionality, however, I’m thinking of another way to do it. Perhaps the simplest way, is to have the CRUD scheme to where it builds based on the SQL for the DBMS and methods. There can also be an abstract class which handles the non-SQL specific code and the Scheme will just need to implement the code to handle the create, retrieve, update, and delete methods. The problem with this, is that it will require modification whenever new methods are added and not all DBMS has the same SQL.
I believe, that by assigning Schemes to CRUD, BREAD, etc that it will simplify the DB SQL for majority of people and work on all of the DBMS that there is a Scheme class. The developers who want to take advantage of the specific SQL features of the DBMS will still be able to use the Scheme component to allow for that as well.
The point is to focus on the API for developers to use and not on the Database specifics. That should be up to the developer of the library to design and setup for the user of said library. So be a bit more clear, the user of the API should never interact with this layer at all and only the layer either directly above the DB or however many layers separates the user of the library from the DB.
Another key feature will be the way to extend the Scheme dynamically. The point of this is to keep from creating a new class to add functionality, but add functionality through external callable that will be managed externally through a plugin specific to the Scheme functionality.
DragonU DB CRUD Component
The most basics of DB access is the CRUD pattern. I’m going to include it for the simple purpose of easing the usage of the DB component. If the developer wants to develop their code using CRUD, then this will allow them to do so. I’m most interested in seeing how many developers use what pattern. The problem of which is that I’d need to have many people actually use the DB component to get statistics.
The CRUD component will include more than just create(), retrieve(), update(), and delete(). The experiment is to see how people use the fluent interface, so there will be extra methods.
- The table() method to specify which table to use.
- A where() method to chain the where for updating and deletion.
- A select() method for chaining or selecting what to retrieve.
- A limit() method to limit retrieval, updating, and deleting.
There will be other methods, which the scheme class will have to support, but shouldn’t extend to the full SQL language. The bits that are needed are to restrict what is retrieved, what is deleted, and what is updated. Extending it further than that is a waste of time to develop for CRUD.
DragonU DB BREAD Component
BREAD is works exactly like CRUD, except you have different and more methods to work off of. The methods are browse(), retrieve(), edit(), add(), and delete(). There difference from CRUD is that the retrieve is both for one or many, whereas the browse() in BREAD is for many and the retrieve in BREAD is for one and only one. The BREAD edit() works exactly like update() in CRUD. The BREAD add() works exactly like create() in CRUD. The delete() methods are the same for both CRUD and BREAD.
The advantage of BREAD over CRUD is in the retrieval. I suppose is arguable whether two methods is better than one. It will be up to the developer to decide whether to use CRUD or BREAD. As it is mainly up to their preference for either one.
Other Patterns
Other patterns will be added as well over time. That is the nice part of the component. I’m not really tied into implementing it in one way or refactoring to allow for more patterns to be added. It is just faster to focus on a few things to get the initial functionality working and usable in projects, instead of having to wait until the majority of it is finished before using the library.
Other Functionality
The functionality covered in this post is just a small part of what most DB component packages offer, so yes, as the DragonU library is developed, more features will be added. It is just better to work off a base that allows it to be done easily and doesn’t require that it all be done at the same time.
Possibly Related Posts: