I am currently working on extending ProjectPier. I am having trouble deciphering how the controller is linked to the model, and how the model is linked with the database (naming convention, direct declaration, etc...) Apparently Project Pier was developed with an obscure framework called Angie, which has no documentation whatsoever. Any experts on this? Help would be appreciated!
Figured this out myself after some tinkering. There is no 'automagic' between the controller and model in ProjectPier. Models are simply referenced by their class name.
There is also no naming convention inside the model. Each table is associated with 4 model files however. Application_log.class.php and Application_logs.class.php are the functional files. Each of these have an associated base class from which they inherit: Base_Application_log.class.php, and Base_Application_logs.class.php. Inside the Base_Application_logs.class.php there is a line in the __construction function which links with the specific database table: parent::__construct('Application_log', 'table_name', true);
That's it! The rest is pretty straight forward. Hope this can be of some help for someone in the future!
Related
I started learning the dart language. when I heard the term Helper Class. I didn't get any clear answer.
Please tell me about
What is the meaning of the Helper Class?
For which purpose they are used
Thank you so much to the kind community. :)
In simple words Helper class is like a warehouse where you can put commonly used operations for other classes. So whenever other classes will need them they can access them.
Imagine you have some code which is commonly used in your app. So there are two ways to use that code.
To write the same code again and again. (Which no one wants and prefers)
To put that code somewhere and call it whenever you need it. And this is a situation where helper class come in to play.
Below are some main objectives behind its creation:
A helper class is created to make code more readable and clearly organizable.
They help to eliminate boilerplate code as they contain commonly used functionalities.
The other goal behind its creation is to provide a common functionality to other classes. In helper class, you can move some methods, variables, and operations, which are commonly used in other classes. So it helps to make your code more organized, maintainable and readable to others.
I hope it helps you. :)
I am trying to understand the MVC Pattern, and I finally understand a lot of it. There is one concept that I don't quite understand yet. I have looked through all the posts on here that try to explain MVC, but this one question isn't answered clearly yet.
Do you create variables in the model or the controller or both?
I can see someone passing variables from the controller to the model to change the data held within the variables, but would it be better to create them in the model then just call their values from the controller? Or would it be better to create variables in the model, and copy their values to the same variables in the controller?
If you know, please explain why one is better than the other, please. I am asking to understand, not just to know the right answer. Thank you.
If I give a straight forward answer for
Do you create variables in the model or the controller or both?
It doesn't really matter.
The main idea behind Model and Controller is
Controller resides only Presentation Logic.
Model resides only Business Logic.
So that, if you want to present your model with a different presentation logic, you can get your existing Model out and plug it with a new Controller without any problem because your business logic & presentation logic is decoupled(not mixed with each other).
This is the best diagram I found for MVC architecture. Hope you can upgrade your understanding with this.
So in terms of variables, in Model you should make variables only for business logic purpose. In Controller, it's only for presentation purpose. :))
Persistent data needed throughout the lifetime of the application should be held within the Model. Model method calls to set, get and manipulate the data within the Model should be done by the Controller.
Temporary data needed by the application or the view (for any reason) can be held in the controller... but no persistent data should ever be held within the controller, as it's considered to be a bad MVC design pattern implementation to do so.
It may sound stupid. And please, redirect me if there is a similar question asked.
But in big projects I often see Classes named Entity or "Controller". Can someone explane to me what are they used for (generally)? Can you provide some examples aswell.
I hope you can understand my question.
In a simple sense:
An entity represents data, for example you may have a Car Entity.
A controller, typically, routes data: "controls" where it goes.
I am currently going through Hartl's Rails Tutorial, and through the first 10 chapters or so have gotten used to the convention of putting most of the actions/methods in the controller. Currently, as the book is going through and defining a feed method for the Microposts, the method is placed with the User.rb model instead. As I am relatively new to the world of rails (and programming in general), I was wondering what the rationale or convention followed for putting this method (copied below) in the Model?
The method placed in the User.rb model:
def feed
# This is preliminary. See "Following users" for the full implementation.
Micropost.where("user_id = ?", id)
end
There is actually quite some contention on what code to put where, but in general, there are some easy guidelines to follow.
Does the method have to know some detail about the underlying data structure? Put it in the model.
An easy way to determine this is when it uses ActiveRecord methods like find, where, or specific columns in the database. By keeping this logic in the model, that means if you need to change the underlying datastore, you only have to change the model.
Does the method have some say in how a page is going to be rendered? Put it in the controller.
Generally, controllers should be pretty thin, pushing data to views and saving form data back to models.
While (if I remember correctly) Hartl does not take about non-rails classes, don't be afraid to put 'business logic' outside of the rails structure. You can create a app/lib or app/services or app/x directory and put plain old ruby objects in there, which can then be called from your controllers and models to handle those things they are good at.
Aim to 'push' things 'up' into the model as much as possible, then they will be repeated less and available to more. Don't just use models for Active Record database tables.
You can often unit test models easier.
Another 'next' place to put stuff that is shared is in /lib
I need some help as I seem not to be able to grasp the concept.
In a framework, namely Yii, we create models that correspond to database tables. We extend them from CActiveRecord.
However, if I want to create a class that will get some data from other models but then will do all the computations based on those results and do something with them... then how do I proceed?
I want to clearly divide the responsibility so I don't want put all the calculations in source db based models. Basically the idea is that it will be taking some stuff from some models and then updating another models with the results of the calculations.
What do I do?
Keep all the calculations in some controller and use required models? (Hesitant about this because there is a rule to keep controller slim)
Create a none db model and then work from there (how?)?
Do something else (what?)?
Thanks for any help!
For you to use the Yii interpretation of Model, you will have to create class, which depends on CModel. It is an abstract class, thus you will be required to implement attributeNames() method.
To use other "Models" with this new structure, you will need to inject them in constructor, or right after your custom model has been created.
In real MVC model is a layer, which mostly contains two sets of classes with specific responsibilities: domain business logic and data access operations. Objects which are responsible for Domain Business Logic have no clue where the information is stored and where it comes from. Or even if there is such a thing as "database".
This video might explain a bit: https://vimeo.com/21173483