Hi there.
I have decided deeply refractore (rewrite) my project. I have been working on it for a year or so, it is functional and reasonably stable. Next I plan adding a lot of new functionality. The project already contains dozens of classes, is relatively complex and will become much bigger after adding the new functionality. I am afraid of getting lost if I just add the new functions, without rewriting and standartizing the code.
Below is the list of tasks I have decided to do. Please note that I am using the terms models, views, controllers without intending to fully apply the MVC architecture, bussiness functionality will reside in controllers, while models will be reduced to fetching data from database. Thus the terminology models, controllers may not be correct.
I am limited by the existing code, thus the points below contain tasks that are already partly done or seem feasible.
I would greatly appreciate your comments and suggestions.
1. Object will not use global data directly but only through constructor
2. All objects will be classified as either models, views, controlers or helpers
3. Every base class will contain comments exactly specifying its responsibility
4. Classes with wide responsibilities will be divided.
5. Classes will be renamed according to their main responsibility
6. Autoload
7. Design patterns Singleton, Factory,Strategy, Iterator will be used at all suitable places.
8. Controlers will
- accept all users data
- contact models for getting data from database
- contain bussiness logic (or use helpers for this purpose) apply this logic on database data
- pass data to viewers for rendering
Models will
- create and execute database queries upon request
- will not modify the data they get, only pass them to controllers or store in database
Viewers
- will not apply any bussiness logic on the data, just formatting
9. Write complete tests for every class.
Refractoring a project
Moderator: General Moderators
- allspiritseve
- DevNet Resident
- Posts: 1174
- Joined: Thu Mar 06, 2008 8:23 am
- Location: Ann Arbor, MI (USA)
Re: Refractoring a project
You may want to start with writing unit tests for your existing classes, and then adding functionality once those are complete. That way, you know everything is working as it should while you add new features. I would recommend SimpleTest if you haven't used it before.
It sounds like from your description of your MVC interpretation that you are still programming in somewhat of a procedural manner (which is perfectly ok). An anemic model and view as you have sort of places everything into the controller. As you go on, you may want to start taking business logic out of the controllers and into the model. The model you have now is basically one (or many) data access object(s). I assume they are returning arrays for the controllers to deal with. If you start creating classes where you once had arrays, that would be a logical place to start telling those objects to do things, rather than taking an array and performing the business logic in the controller.
Good luck!
It sounds like from your description of your MVC interpretation that you are still programming in somewhat of a procedural manner (which is perfectly ok). An anemic model and view as you have sort of places everything into the controller. As you go on, you may want to start taking business logic out of the controllers and into the model. The model you have now is basically one (or many) data access object(s). I assume they are returning arrays for the controllers to deal with. If you start creating classes where you once had arrays, that would be a logical place to start telling those objects to do things, rather than taking an array and performing the business logic in the controller.
Good luck!
Re: Refractoring a project
First of all thank you for the reply and suggestions.
You are not exactly right saying "you are still programming in somewhat of a procedural manner". E.g. I am using factory classes to construct several paraller object hierarchies etc. But yes, you are right, I have either difficulties with placing business logic into models or I do not understand the terminology well. One of the reason is that I prefer complex database queries. So the data are already well sorted and not much logic need to be applied on the recovered arrays. Usually suffice to pass the recovered array to the controller, perhaps through an iterator class. So there is a whole bunch of controllers, starting somewhere with the user input, doing all business logic, requesting or modifiyg data through simple models (well data access classes) and passing them to viewers.
If there are potential pitfalls in this approach, I would like to know them.
You are not exactly right saying "you are still programming in somewhat of a procedural manner". E.g. I am using factory classes to construct several paraller object hierarchies etc. But yes, you are right, I have either difficulties with placing business logic into models or I do not understand the terminology well. One of the reason is that I prefer complex database queries. So the data are already well sorted and not much logic need to be applied on the recovered arrays. Usually suffice to pass the recovered array to the controller, perhaps through an iterator class. So there is a whole bunch of controllers, starting somewhere with the user input, doing all business logic, requesting or modifiyg data through simple models (well data access classes) and passing them to viewers.
If there are potential pitfalls in this approach, I would like to know them.
- allspiritseve
- DevNet Resident
- Posts: 1174
- Joined: Thu Mar 06, 2008 8:23 am
- Location: Ann Arbor, MI (USA)
Re: Refractoring a project
I guess I meant your approach, rather than the actual code, is procedural. Having the controller do virtually everything (especially business logic) is still prodedural, even if the controllers themselves are objects. Pitfalls are the same as any OOP vs. procedural debate.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Refractoring a project
Just some personal opinion comments:
There are many other types. I would not limit myself with a rule like this. It is more important that models, views, controllers are clearly defined/separated rather than everything being put into one of those boxes.mach wrote:2. All objects will be classified as either models, views, controlers or helpers
I think you mean what is usually referred to as Separation of Concerns. A class may have wide responsibility while still being focused on a single concern.mach wrote:4. Classes with wide responsibilities will be divided.
I would recommend only using Singleton if there is absolutely no other reasonable solution.mach wrote:7. Design patterns Singleton, Factory,Strategy, Iterator will be used at all suitable places.
Controllers should not have 'business logic'. They are really mainly for Request handling and program flow.mach wrote:- contain bussiness logic (or use helpers for this purpose) apply this logic on database data
The View can get data directly from the Model if it makes the code cleaner and clearer.mach wrote:- pass data to viewers for rendering
Models certainly should modify the data. They should do most/all data modification because that is their concern and specialty.mach wrote:- will not modify the data they get, only pass them to controllers or store in database
(#10850)