I've been told to use some ORM library to make storage easier.
I've read about Doctrine, RedBeans and some other ones. I'm giving RedBeans a try because it's quite simple and requires no configuration.
I already tried some basic code to store beans and so.
If I want to have a model class (a bean?), to add some basic behaviour and functions.
What class do I need to extend? What methods do I need to override and then how should I get an instance of them?
Example: a Blog class which contains a User and Posts
The answer to my question was a feature of RedBean called 'Fuse'.
It was as simple as extending RedBean_SimpleModel class and implementing delete and update methods.
The downside of RedBean is the lack of tutorials/documentations (their wiki is really poor)
Related
Basically im doing a "enterprise application" and i want to make code as flexible as possible while keeping it somewhat scalable(its for personal use for now so i don't need to be ultra professional)
The thing is many entities share the same fields and since im trying to learn laravel more in depth i thought that the models (and by extention the traits) acted like some ORM's i've worked before where they would create the sql stuff for me.... they don't so i started doing the migrations but now i see that if i could acess certain columns in the traits it would make the code a lot cleaner and more understandable
basically what i want to do is something like
trait hasValue{
public function getStuff(){
$ret = ModelAttachedTo::select("value", "price")->get();
return $ret;
}
}
Edit: I ended up realizing that with this and other shortcomings of laravel to just completely change back end although if a answer comes i will try to see if it fits the question and works as intended
I don't know if there's simplier way to do this in laravel but in PHP world, you can do this with abstract methods. Traits can declare abstract methods which have to implemented by classes.
So declare an abstract "getPrice" method in trait. All of your classes have to implement that method. And you can call it whenever you want.
I am new to Symfony2 and I am not sure where I should save a class that updated multiple tables(entities).
From reading documentation and tutorials it says I should not put any other tables reference within the entity class; I could put it within the controller class, but again many people have said this class should be as simple as possible and not include business logic; Not in repositories, because these are used for query data and not for update or inserting.
Is there a standard folder structure where another type of class for working with multiple entities(tables) should be saved? Should the business logic really be stored in the controller classes?
Symfony2 is very flexible in this regard.
You're right, entities are for one "table" only.
I would suggest you look into Services, as they are a good way to move your code from a controller to a separate class. You basically call your service and use the functions it provides. This will slim your controller down.
I am not sure what I'm doing is called ORM or Active Record Pattern.
I have an Entity base class that entities/database tables will inherit. These classes will have methods like
find
findBy
findAllBy
insert
update
delete
Getters & Setters for column data (eg. name, title, etc) via magic methods
Problem now is how do I create a database connection?
Dependency Injection - sounds complicated ...
Use a global variable, that these classes will expect to be set? - Doesnt sound right
Have a base class that Entity inherit that contain all database connection info? - doesnt sound right either
Maybe I am doing it wrong? I am open to any ideas, preferably simple for a start. I am wanting to create a simple framework for a start (not using Doctrine for example), it will give me a foundation on how such framework works. Also if its a small project, using a big framework may over-complicates things
There isnt really much thats simple about what youre attempting. Its complex thing :-)
You need to have some kind of basic entity manager and/or table class which usually holds the reference to the DB connection (or some sort of object that wraps it). All the Entity's then pass themselves to the manager when their save or delete methods are called and the manager will work out the query needed to modify the db.
You can either inject this manager, or make it a singleton and have your classes fetch it when instantiated for example.
If i were you i would check out PHP Objects Patterns and Practices by Matt Zandstra. It goes into all these patterns with some basic implementation examples.
I am a 4 days old yii fan and I like it so much.
I have a special database table that can't be used by CActiveRecord directly. My solution is to subclass CModel to have my own logic for listing, creating, saving and deleting records. My new CModel subclass cant not instantiated; it seems that CModel requires more methods to be defined to allow creating an instance from it.
My question is: Is this the right approach to go or there are better ways? If yes, what are the missing methods to define to make my new class complete; not abstract
Thanks
I usually create my own classes to handle the so called 'logic' of the webapp that I'm building.
I place it in another folder (usually the logics folder) and auto import the directory from the config. The logic classes doesn't subclass from any Model
public class ProfitLogic { ... }
where inside the class(es) I implement functions that instantiates and use any ActiveRecord(s) that I need.
The reasoning for this is that when prototyping I often refine my database design, and I need to regenerate the ActiveRecords again :p
Your approach is fine generally speaking, and would be fine even if you were not "forced" to adopt it. I use a CActiveRecord subclass as the base for my models to provide additional custom functionality.
As for your other question, you only need to implement attributeNames() to be able to instantiate objects of your class.
However, why do you not subclass CActiveRecord directly instead of CModel? You can still override any and all methods you choose to. Is your database so dramatically different from the usual schemas that you won't be able to reuse any of the logic?
I'm fairly new to Yii as well, but have found that extending CForm, as in the default ContactForm model can be useful.
Not the best for having lots of heavy business logic, but it touches on your point of breaking out of the typical workflow.
I need help in designing my PHP classes where I need to extend from multiple classes.
I have a general class, Pagination.php that does all sort of pagination and sorting. All other classes will use this for pagination.
To make my life easier, I made a class generator that generates a class from MySQL table. All the properties, getters, setters and common methods are created automatically, which really saves time and money.
As an example, class Staff_Base in Staff_Base.php is generated automatically from SQL table t_staff.
Since class Staff_Base is automatically generated from SQL table, any 'custom' methods / properties are located in another class that extends Staff_Base.php. (So that whenever a new field is added, I can simply regenerate Staff_Base class and overwrite in Staff_Base.php).
So I have class Staff.php that extends Staff_Base.php.
The problem is, Staff.php also needs to extend another class, Pagination.php.
(The current workaround is to put methods in Pagination.php into every class. This is really troublesome whenever I make changes to the pagination/sorting methods.)
How do I do this?
What is the best design pattern to achieve this?
I know common suggestions to restructure my classes, but I really think hard of other workaround/solution. Also, I may also need to extend other classes than Pagination.php.
Thanks!
Can you have your generated Staff_Base class inherit from Pagination? Or does Staff_Base already inherit from another base class (that you do not have control over)...
Sounds like either Doctrine or Propel, I do not recall which uses the *_Base class system.
My suggestion would be to rewrite pagination to be able to be used by your entity classes instead of requiring your entity classes to extend it.
So if I am reading what you wrote correctly, since you can't inherit from 2 classes you are duplicating paginate into every class you have.
Class stacking is a solution. One of the first things I googled.
I would recommend changing your Staff_Base.php generator to make that class extend Pagination by default. That way Staff extends Staff_Base, and Staff_Base extends Pagination. I think that's probably the cleanest (and most object-oriented) way of getting the results you want.
you cant, multiple inheritance is not supported in php, but if you do a google search on this topic you can find some workarounds...
It sounds like you're mixing things up here. A class (such as a Staff class) is used to represent a single entity. Eg:
$john = new Staff('John');
How exactly does the paging fit into this? Being page-able (paginatable?) sounds like a property of whatever it is that allows access to these Staff entities, not of the entity itself. That way, the way is clear for each type of Staff class you create to inherit from the base class.
So, what I believe would be the solution you need:
A Staff class (Staff_Base, and its graph of children)
A Staff Data Access Object (DAO\Staff would be a nice name, if you're using namespaces)
An Interface, to signal to the world that a DAO can be paged
Import to note is that there is no direct inheritance between the DAO class and the Staff class. You can still generate the Staff_Base class based on its properties in the database, and extend from there... as long as you don't include the actual data access in that class.
The code using this would then look something like this:
<?php
$staffDao = new DAO\Staff;
$staffMembers = $staffDao->getPagedResult($start, $amount);
?>
Edited to emphasize that the inheritance structure should be separate from the actual retrieval
Well, you might already know that PHP doesn't support multiple inheritance. One way around might be using Interfaces instead of superclasses, although, if the logic is identical for each implementing of the interface, this might become tedious. How about writing a code generator, that simply injects the methods to each class? You seem to already do that on the "common methods".
Oh, and using getters and setters (as they are used in e.g. Java) in PHP is considered not a good idea. Objects are slow as they are, so using public fields is considered the norm.
Edit: Then there's the __call()-hack, which could recognize the methods that actually reside in your other classes, and call them manually.