Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
I have a problem about structures of the complex applications. Because my knowledge background does not come from education, I have always had a problem understanding an application's layers, design patterns, and programing structures. First of all, I can do whatever I want with PHP, because I know common functions and I have experience with it, but I want to create bigger and more complicated applications than I did before, so I always ask questions myself while I am writing code: Is this best place to do this? Is this the best way to do this? Do people use this way to do the same thing?
To answer these questions correctly, I created my own small MVC PHP framework which really looks like Zend Framework. I did this because I want to clarify all parts of the application. I know that there are lots of design crimes in my framework and all my applications, and I think that the main problem is the border between Controller and Model.
I asked lots of questions about this on SO, but still it is not clear for me. Therefore, I will explain what I know and what I do, and please show my mistakes, and correct them, or just explain some information about design patterns, or just explain what my problem is.
What I know
I know active record pattern. For example, we have user class, we use same class to save data to database, and we use same class as a object. So object is active we can create one then if we change it we can save it with same class ( $user = new user('Oguz'); $user->save();)
I know factory pattern . We have to classes for one object (User_Factory and User). We use user_factory class to access database for example get user or delete user. And user class is the object it self.
My problem starts when there is a connection between objects (not like many-to-many or belongs-to). For example, we have a video website which has a favorite system. The process of adding favorite consists of these steps (1-check the video with this id, check the user with this id. validating steps). While we are just adding or updating just one object we user other objects too (User factory and video factory). Generally I can do all this things in controller. But I fell that this is not the best place to do this. Because I call these steps as a process (adding favorite process). So this process should not go in controller because we may want to use same process as an API in another controller-action. So I feel like there should be another place which includes this processes for example process library. I do not even know which programing problem I am talking about.
The connection between object does not just exist in validation step.For example think about search process. when user search a string first we have to create new search row (for latest searches stuff), then we have to search YouTube, if we can not find we have to search other video sites et cetera. So this action is a process search process, I think putting the all logic in controller is a correct way to to this. we use lots of classes and objects so I can not put this process in search objects class.
I think one of the best things you can do is dig in and understand, really understand how things work. In the arena of web development, we are typically isolated from the details of TCP, packets, transports, protocols, etc... But sometimes, it is so isolated, that we forget to learn how it works, and as a result, stick ourselves in a little box.
I've been programming PHP professionally for nearly 10 years. I've never used an MVC framework. I've always separated user interface from application logic from database access.
We don't need a bunch of "patterns". We need true understanding of the problem, and the vision to create an elegant solution, re-using other work as much as possible.
So I guess I am suggesting that you switch your focus from trying to make your application fit into a pattern, and re-consider the logic needed to successfully complete your application. Many times, it is very simple, but we tend to over-complicate it.
Throw off the handcuffs of MVC and patterns... (and then watch me get downvoted for ranting against the status quo).
Good luck with everything. And by the way, you will learn far more about programming in 4 years of doing it, than 4 years of college. Not to say you should or should not go to college, but just be aware that in many cases, you already know more than your professors will about real-world programming.
MVC is a fashion blooming 20 years late. If you feel it pushes you into "wrong" code, it's because that's just what it does. Do things from the first principles. And... The community is not a shrine of divine wisdom. We're just a bunch of loud code monkeys. Use your own brain. And... MVC is a fashion blooming 20 years late. If you feel it pushes you into "wrong" code, it's because that's just what it does. Do things from the first principles. And...
Good luck, and enjoy your endeavors!
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Greetings,
I would really love to hear about your broad knowledge about application design on this one!
I'm new to Phalcon, and now building my first MySQL & RESTful-API based application with it, but encountering some challenges along the way.
First, about my application design, the concept is as follows:
An API as a core for the application, wrapped by a "UI shell" of pages and views that utilize it.
The API is supposed to be composed of a set of Phalcon models that represent the DB and business logic, and over them, a component that acts as a layer that makes those models accessible as "HTTP services" - generally by translating requests to model names, and the HTTP verb to the appropriate model action (e.g: GET => $account->find()/findFirst(), PUT => $account->update([params]), etc.).
I was sure that the Phalcon models are gonna rid me of having to write most of my SQL, however, soon I came across some pretty common scenarios that the models couldn't handle the way I would expect:
You have entities like messages for example, and you wish to query them using a column of some other, related entity (like the FIRST NAME of the user that owns those messages). A model can't do this in a single operation.
I want to show a list of messages, each attached with the details of the user that sent it. In Phalcon, the first thought that comes to mind is taking advantage of the model relations feature, but thinking further I came to realize that will perform a full query for every message rendered, which is a disaster performance-wise, rather than retrieving them all together with their user details in some single, JOINed query.
I want to show a list of users, each with a total messages count. Found no other way to achieve that rather than a full query that includes a COUNT() field & GROUP BY or a sub-query.
I tried to look up such use cases and others, for most of them there hasn't seemed to be any elegant solution.
The Point:
What I want to achieve is a API-based architecture that makes sense, scalable and easily customizable to real world scenarios (being able to handle obvious situations like demonstrated above).
What would you do in Phalcon to handle the problems I encounter?
What do you think about the design concept I took? Is it somewhat standard and makes sense?
Most importantly, how would you design a full & flexible API without repeating cumbersome SQL queries everywhere, if at all?
Do you have any references or examples of known companies' approach on this?
That's a big question and any help will be huge!
Thanks!
Dor.
Little disclaimer first: There's no straightforward answer for this question(s), so Stackoverflow isn't the place for them. But since you have put it nicely I'll try to help :)
Almost any modern CMS API has a very similar approach that is very successful and flexible, you can follow their guidelines to implement your own API. I'd recommend storageroom and contentful documentation pages, they have a series of gotchas and patterns that I've successfully added to my own projects eventually.
Phalcon is a good choice for a RESTfull API and a proof of that is the PhalconEye project, a cms built using Phalcon. Once you have designed your API, go check the PhalconEye source code to get some samples on how to implement such things with Phalcon.
Good luck!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm trying to understand advanced PHP OOP principles, having programmed procedural Php for years. I wondered if there is a rule of thumb for how best to group functions in to classes and how to plan which classes to abstract / extend? If not, could you recommend any advanced reading that might help.
I have read a few (self-defined) 'advanced' OOP tutorials. The examples have taught me the basics for how to create very loosely coupled objects with very minimal attributes defined in heavily abstracted classes. I've also read other (bad) tutorials which basically turn functions in to methods and encapsulate them in classes - and I know they are not written well so don't want to emulate them.
However, I'm not clear how to decide which classes to build my project around - I'm not sure if I should think first about the macro features of an application or about the frequently carried out actions.
Take for example a website in which:
- Users can sign up and have different privileges depending on user
levels
- Users can edit their user details, upload photos, sign up to a mailing list and join groups with other users
- Admins can create new sections in the site within 5 different module areas
- Users can post articles and comments within these different distinct sections
1) If admins can create a sections within 5 different module areas (single, double and triple level blogs, forum, poll) should I think in terms of 1 class per module?
OR 2) should I generate a new 'class' for every new section an admin creates?
OR 3) Users are the central focus of the entire site - Users interact with the modules and the sections - so do I create a large user class containing insert, edit, delete methods?
Following on from that, where is best to put the methods?
a) I'm going to need to freuently use an SQL insert clause - I'll need to insert to the user table when someone signs up, insert to the groups table when someone makes or joins a group, or posts an article, comment or IM - so I'll use a method like the following... but should this be nested inside all of the other classes, or repeated in each of the module classes?
// runs a sql query
public function runQuery($qry) {
$result = $this->mysqli->query($qry);
return $result;
}
Likewise things like emailing the user multiple times - when they sign up to activate their account, when they join a mailing list, if they forget their password... So I imagine I would need a method for that.
As you can see, I'm confused as to to which class I should I put my methods in, and which classes to build my site around.
I'm fairly sure that I shouldn't need to think through 'all' my features before I start, as that wouldn't work well with an Agile development environment where users might suggest new features, so I'm hoping there is a relatively simple bit of guidance you might be able to offer me.
This is just one of many examples of sites I've previously coded procedurally and now want to start thinking about in OOP terms, so any pointers would be hugely appreciated!
Thanks
It's very difficult to come with proper solution without understanding what do you really want. When you are facing a problem/feature request you have to design application. Everything depends on feature/issue.
There are many different solutions, and each one is good for specific case. I cannot answer your question without deep understanding what do you want to tackle. The only think that I can advice :
- KISS - Keep it simple Stupid
- SOLID Principles, especially Single Responsibility Rule - each class should be responsible for only one thing. For example if you have User object, you should have at least three classes. UserEntity or UserDomain - simple representation of object, Repository/Storage for that user that brings you the basic operations on given user (CRUD - Create,Read,Update,Delete), and then you should have a module,service that handles the interactions, (for example between different users). The less one class know the better.
The good way to start is reading at least a little bit about design patterns, SOLID, maybe about DDD (Domain Driven Design). Also I can suggest watching CleanCoders. Uncle bob has very good (in my opinion) video tutorials about software development.
I used to say, that if you want to do something correctly, you have to do it twice. At first approach you don't know what you can expect, you cannot come with best solution without deep understanding what you're facing.
When I'm writing a piece of code, for example a class, I'm always writing it at least two times. Almost each part of class is refactored during development in order to remove duplicated code, improve perfomance. It's very rare when developer comes with perfect solution at first time.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I want to start by saying that I searched a lot for this exact question, but none of them satisfied my needs.
I program Php, MySQL, HTML, CSS and Javascript the 'old way', using just a text editor and building every website from scratch. I built websites from the most simple to an-almost e-commerce just by coding every piece of the application. The most advance thing I did was using some simple classes, like a database wrapper, singleton, and for the rest I always used functions.
Now, recently I signed up for a website where there are courses ( I won't say its name because I don't know if I'm allowed ) and I followed one about Laravel 3 ( I know currently its version is 4.x ), and I must admit I fell in love with it. I like it very much and I want to start using it but I'm afraid that doing so will 'dumb' me.
What I mean is that Laravel has a lot of helper functions, Eloquent structure and so on, so by using it I won't learn any more the pure Php because for everything you need there is already a built helper function.
To make a very simple example, if you want to join some tables you use Eloquent and within literally 3 second you accomplish this. If you want to log a user in, again you have an Auth class that does everything for you, even setting sessions.
This is my biggest fear, that I won't learn anything anymore because all you need is already provided, you don't have to think that much anymore.
On the other side, Laravel helps you a lot and it eases your work very much. As much as I want to start digging into it more I can't help but fear its downsides.
So, do you think I should wait and learn more traditional Php before dive into a Framework?
When is the right time to start using one?
Look at all the sites you built. Identify redundant elements. Extract them into classes and functions and build your own framework. This will allow you to build sites faster and build a library. Once you do that, there's no dumbing down. You can choose to use another or not... but you'll have yours too.
That's what I did. I have my own framework. And it ain't bad!
There are two types of developers:
users - they can use stuff and get by
actual developers - they can build stuff from scratch and give users tools
Choose which model fits your needs best.
1st category goes for quick results, are efficient and get the job done. These guys should use 3rd party frameworks and libraries.
2nd category are artists pushing themselves further with each new piece of code they build. They go for performance over turnaround time, code beauty and functionality vs. just functionality, etc... These guys feel offended by 3rd party frameworks and libraries and always roll their own. Because they can!
There's another catch. Some frameworks might have too much fat for your needs. Building more specialized solutions might actually yield way better performance than a one-size-fits-all framework. That's another perspective.
Bafta mai departe :)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Me and my friend started working together as partners , we have decided to make Kick-as* website after website.
We have the ideas written down like 100's of them (yes we are choosing best and easy among them first).
My friend does the layout design and arranging things , and my part is coding and server management.
The little problem i am facing is lack of experience in planing a project. What i do is, I just start the code straight away and along with code I make DB, like when i need a table i make it.
I know this is very bad approach for a medium sized project.
Here at stackoverflow i saw lots of experienced coders. Need to learn a lot from you guys :) .
So can you plese help me on how to plan a project and what coding standard/structure/frameworks to be used (I do PHP code).
Thanks in advance.
Start by defining the scope. Write a paragraph to a page and try to describe your website. A top-down approach would be to start thinking of functionality you'd like to implement and refining it by adding more detail.
A top-down approach (is also known as step-wise design) is essentially the breaking down of a system to gain insight into its compositional sub-systems. In a top-down approach an overview of the system is first formulated, specifying but not detailing any first-level subsystems. Each subsystem is then refined in yet greater detail, sometimes in many additional subsystem levels, until the entire specification is reduced to base elements. A top-down model is often specified with the assistance of "black boxes", these make it easier to manipulate. However, black boxes may fail to elucidate elementary mechanisms or be detailed enough to realistically validate the model.
http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design.
There are many other approaches, however.
http://en.wikipedia.org/wiki/Software_project_management#Software_development_process
Again, the most important step is to be able to put your idea in words; before you can adequately do that, I wouldn't even consider starting to write one line of code.
Regarding coding standard/structure/frameworks I recommend zend framework coding standard, MVC structure, and Zend Framework.
A brief guide for a MVC architecture. The idea is tho help you remember ideas (while your brain is steaming code) and have documents for future programmers.
Design the database. Make an ER diagram. Put it in a document.
Briefly describe reasons behind the design for the important issues (why you choose a polymorphic relation, why use this view, what selects you expect that are more trickey etc.). This will change as you code (and there is nothing you can do). Document the changes. To cope with the changes, use a versioning system for the database like rails migrations.
Design the structure of your website (sections, pages, links, page-flows etc.). Document it. (like: "the site 2 sections, this section is made of ..." etc.)
Based on this make a document describing your controllers and views. ( "a controller for articles, with a list view, and article view, also edit and create views but just for admins" etc).
Describe how you are going to enforce authentication and authorization (on controller and view level). Who is allowed where.
Describe how you protect against the main web-attacks (xss, csrf) where required. (example: "i escape all my view variables using htmlentities for xss protection and ...")
Design your models and side functionality (sending emails, background jobs etc.). These will be the bulk of code. Document each and describe the main issues (for example how timezones are to be handled, how this certain model is to connect to the currency service, how that model is to parse and manipulate some crone file, what algoritm you shall use to decide top 5 articles, depending on your app.) Describe what libraries you use, how, and for what purposes (example: "we are to use curl to scrap SO and make rss feed")
Describe how you protect against the main web-attacks where required (sql-injection, xss).
As you code, things change. Your knowledge about the discrete works of your system evolves and you start to improve the design based on the new found enlightenment. Document your changes.
A few thoughts from someone who loves abstractions.
Figure out what your websites will have in common. Once you have identified the main commonalities, look for frameworks or libraries that deal with as many of them as possible (besides filling your other criteria), such as the boilerplate DB code.
For the common features that you can't find any ready-to-use code (they always exist in customized websites) you'll have a chance to write a common library to be used across your websites yourself. This could be a template for your markup, a JavaScript library or a reusable server-side component, or all together.
Based on your description it sounds like you are enjoying great freedom in the creative process (versus getting a requirements spec handed to you and asked to implement it). I'd say don't over plan either, "just starting to code right away" is a lot of fun and not all bad. Experience will be your best friend, and by the time you reach website #100, you'll have lots of it. When building your second website, your experiences with the first one will help you avoid making some of the mistakes you made, and you'll discover new similarities that you did not anticipate in the planning phase. Just make sure to take the time, move the common code to a single library, and go back and edit your first website to use it. Do this a few times over and you will have learned lessons that are worth a lot.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I’m working on a project and have developed the high level user requirements for what the system must do. This project is a php web application built on the CodeIgniter framework. Now I’m trying to take those requirements and break them down further into controllers/actions. What is the best way to do this?
I was thinking of creating a word document with a table that would have four columns. Column one would be the the name of the controller, column two would have the actions, column three would have the name of the view that is specific to the action, and the fourth column would show which users had access to that action. Does this sound like a good idea?
I like the interface first approach to building an application, but realistically, I need to know what views I need before I can create a prototype interface.
Could anyone help me out with how to plan the app and any documentation that might help?
Your breakdown is a good idea, but it's really the second step.
here's what I'd do:
take your requirements, and turn them into a series of scenarios ("use cases", "user stories").
Pick one, and sketch, like on paper, the basics of the user interface you'd want if you were to have the Good Code Fairy deliver the perfect system to you.
separately go through the scenario, and underline all the nouns in the story; those are probably domain objects. Underline all the verbs in a different color. Each verb is a method of one of those domain objects. (In fact the domain object will be the object of the verb. Cool, huh?)
Figure out how you would implement that user interface using those domain objects.
Build it
Show it to your customer, who will invariably say "I like it but"
Put the changes and things you learned inot your requirements, and repeat until the check clears.
Peter Coad wrote what I still think is really the best beginners book on this: Java Design: Building Better Apps and Applets. It's oriented to Java, but the design part is universal.
Your domain objects are the model, the display of your data is (roughly speaking) the view, and the code attached to actions is the controller.
On Use Cases
The "right way" to do use cases or user stories is subject to immense discussion and religious warfare. There are zillions of options, from Cockburn's somewhat complex form, to notes scribbled on index cards.
For the kind of application you're describing, I do two things: I try to keep them to 25 words or less, and I think about the SMART acronym.
Twenty-five words or less helps keep them small. Doing a few small stories is preferable to spending weeks on a big one.
SMART stands for "Specific, Measurable, Agreement with Responsibilities and Tests." (Or at least that's how I interpret it. There are other versions.)
Specific, you have to be comfortable you know what's being asked.
Measurable, you have to have some way of testing or some kind of statement of what will be acceptable
Agreement, because it needs to be something you and the customer can both agree satisfies a need — in other words, the "meeting of minds" of a contract
with Responsibilities, you have to know what you're being given, what the customer or user is responsible for providing, and what you are
and Tests, in other words, you should have an effective procedure that gives you the answer "it is acceptable" or "it's not acceptable."
The form I use has the pattern
User in a particular role
does something
resulting in some benefit
So, in your example, I would write
Administrator (who?)
lists all FAQs (does what?)
to review them for updates. (why?)
The "resulting in some benefit" part is something I emphasize and a lot of other people don't, or don't even mention. It helps a lot later if you need to prioritize them.
The "test" part is a description of an acceptance test: you're answering the question "Is this done?" So the acceptance test might be
A logged in administrator selects "list FAQ". All known FAQs are listed in correct format.
Ideally, you'd set this up so some tool, like expect or a gui test tool, can run this automatically, but especially in a small projects you may end up testing by hand. You want automated testing, because as you build the system, you want to do regression tests; that is, you want to repeat your tests to make sure nothing has been broken by a later change.
What you do is you work user-centered.
You make rough mockups of the screens (use Balsamiq or something), and show them to your client/stakeholder, and walk them through it (as if they were using it). Get them to agree.
Then you code the thing (I'm sure you can figure that part out)
Then you show to your client again (have them actually use it in detail), and agree on changes.
Now you finish it
Good luck!