I Often ask this question to myself again and again. what is the use of encapsulating the data in PHP. although i do understand it's usage and usefulness of hiding the data or design implementation of an application from Public. i do agree this way i could achieve lots of security by not allowing other developers to see how i implemented other methods. now in case of PHP i still have some unanswered questions.
a) How does encapsulating data in PHP
gonna help me because as PHP does not
provide any encryption system (i know
there exist few but i am talking in
general) which will encrypt my source
code from being read by others, anyone
can always comeback see my source and
modify accordingly breaking the rules.
now this lays down the whole purpose
of data encapsulation isn't it?
Now there may be different situation i may have to handle using PHP let me take into consideration two scenarios where i have two deal according to the situation.
SITUATION A :
A Clients wants me to develop a Web
Application, Which will be stored
locally into his desktop machine and
accessed from there. in the context of
this situation i can do nothing to
make sure no one touches the source
code. Encapsulating the data is of no
use here i see. isn't it?
Situation B:
I need to develop a Web Application
which will be hosted in server and
accessed from there, and i have
defined several class which is bounded
by encapsulation, but i want other
developers to extend the class by
making use of Public API. i really do
not have any idea on how i can allow
anyone(developers) to extend using my
class in this situation? i am really
not sure on how public API things
work?? i will be grateful if someone
could put some light on the logic
behind implementing PUBLIC API. and is
this where Data Encapsulation comes
into picture? is this the only
situation where i will badly need
encapsulation to be implemented
within my application?
Thank you.
You do not use Encapsulation because it prevents people from touching your code but because you want to create a limited but dedicated public API for your objects to exchange messages through. This a key element in in OOP paradigm. The aim is not to security but maintainable and flexible applications. If people want to modify your code, let them. They are grown ups.
I believe you are mixing conepts here. One thing is the design principle of data encapsulation, another concept is the availability of the source code or reverse engineering.
Data encapsulation is important to your development team. Its advantages are the fact that code is more reusable thanks to the clear interfaces and the code is more easy to read and understand because data are logically separated.
This has nothing to do with code availability and possibility to reverse engineer your code. Even if data are encapsulated, your code can still be viewed and analyzed.
Those concepts meet when you are publishing a closed source library. You want to make sure that it has a clear public API, provided as an interface, and you want to make sure it is encrypted so nobody can copy its internals.
Related
I'm interested in hearing about advantages and disadvantages of developing a web application using the OOP paradigm instead of Procedural.
I am NOT interested in
OOP vs Procedural
Contexts other than a typical web application, meaning a distributed application where a client makes an HTTP request to a server
My question is motivated by the fact that I've been developing a web application running on my company's Intranet, and would like this application to be "easily" maintainable by the person who will replace me, eventually, so that the application stay and is not replaced by some over abstracted over engineered paid solution a very few people will enjoy working with.
I posted some bits of my application source for review at codereview from wich I didn't get a lot of feedback. I then posted a link to my post on codereview over at reddit/r/PHP that didn't go really well.
For now, I am under the impression that the vast majority of the "web development" community have decided that OO is the way to go. I'm having a difficult time to understand why BUT I have a feeling that the next dev my company will hire will also be a strong believer in developing OO for a web application as it seems to be the norm nowadays.
I would like to agree with them and join the bandwagon, can someone try and explain to me the advantages and disadvantages of OOP in the typical context of a web application.
While doing some research I came accross this really interesting comment and this one too, wich makes it even harder for me to make the switch.
A small quote from one of the comments:
OOP is for people who can’t properly engineer software or for competent programmers who are involved in very large or complex non-web project. If I were to write an event-driven game to run on a PC, I would not choose procedural programming.
The selling point of a lot of web application frameworks these days is it is an MVC framework. You have the Controller that interfaces with the View and the Model. The model is your business and data layer which contains business objects/entities/data objects - well basically objects that communicate with each other using messages. The objects themselves are restricted to what it is unique to it and only what it can do.
These boundaries/restrictions somewhat make it easier for other people to understand your code and how to modify it. It also helps in unit testing each one of these layers separately.
I suppose if you wanted Rapidly developed application with the controller querying the database and sending information to the view, you could do that too. But the only way to test would be to run the application, check if something breaks, fix, restart it, again test.. You would not be saving a lot of time.
EDIT
You are using a single controller which has business logic in it. But your model looks very much like what an OO model should be. So the question I'd ask is, what happens if I break this controller to be domain specific? I would then have to create a UserController and a DepartmentController and UserController renders all views related to CRUDing Users. Is that worth the trouble? Absolutely. Someone else could jump in and work on AdminController or ReportingController, whatever your application needs without having to worry about changes you are making to this controller.
And if one of you colleagues wants to see some changes done to the Department section, you don't need to worry about the rest.
First of all I'm not a Php person at all but your self praising question seemed interesting so I researched a bit. My answer is general and is not related to a particular implementation of object oriented technology or web technology.
An object encapsulates the data along with the relevant functionality all in a single piece. it is not to say that you encapsulate your whole application inside a single giant object. A lot is related to how you analyze the problem, identity objects and use them.
A web application as a request-response thingy maybe true in early 90s but now the web apps are mature. It is not necessary to follow a typical request-response scenario. Have you seen a stock tracking app? it does not wait for a request to send a response. it sends whenever the data is available. I worked on the online candidate testing web app which asks questions in fixed amount of time. Once the time is up it ends the test whether the user "requests" to end it or not and results are displayed. Even if it user machine is turned off or there is a network issue, it remembers and never asked the same questions again nor extra time was ever given.
Yes there are bad programmers or "IT-guys" who are totally unaware of OO-analysis. They program the object oreinted stuf in a very procedural way. The result of their work is a request-response styled web app with 3 global variables and a 'z' namespace but that does not mean that the blame should go to the OO paradigm itself. It goes to the people who didn't understand it so much for apply it at the right place!
Im a newbie PHP programmer and I have a few questions about creating a REST based API service.
Basically, its going to be a github open source project which is going to scrape various data off the web and offer it as an API in XML. Now here are my questions in terms of how should I or how can I do this.
1) Since there isnt a robust/same pattern for getting various data through scraping, what is the best way to actually output the xml?
I mean the PHP file would have various lines of extracting data from various points in the code and the file would be a lot of lines. Is it a good idea to type the code to output the result in there?
2) Is there a way to organize the scraping code in a sort of class?
I cant think of a way that would work besides linear approach where not even a function is created and you just apply functions (in general).
3) If theres a way to do that ^^ , how can it you output it?
Is there any other approach besides using another file and getting the contents from the main file and displaying the code through the secondary file.
4) If I were to offer the API in XML and JSON, is there a way to port from one result to another or will I have to manually create the fields in json or xml and place the content in there?
I might have more questions that might arise after these have been answered but I hope I get everything cleared up. Also, this is assuming that the results are not fetched from a DB so the data has to be scraped/tabulated on every request. (even though caching will be implemented later)
Thanks
This question is probably more appropriate on https://codereview.stackexchange.com/
Not to be rude, but a newbie programmer developing an API is like a first-year med student offering to do open-heart transplants for free. I understand that you believe that you can program, but if you intend to release publicly accessible code, you probably need more experience. Otherwise guys like me will muck through it and file bug reports ridiculing your code.
That said, if you want theory of good API design you should probably check out Head First Object Oriented Analysis and Design. You'll want to focus on these key concepts
Program to an Interface, not an Implementation
Encapsulate what varies
...and follow other good design principles.
...honestly, there's a lot to cover to good interface and good systems design. You can use this as a learning exercise, but let people know they shouldn't rely on your code. Though they should know that screen scraping is far more brittle and instable than web service API requests anyway, but many don't.
That said, to provide some initial guidance:
Yes, use OOP. Encapsulate the part that actually does the scraping (presumably using cURL) in a class. This will allow you to switch scraping engines transparently to the end user. Encapsulate your outputs in classes, which will allow for easy extension (i.e. if JSON output is in a Single Responsibility class and XML Output is in another, I can add RSS Output easily by making a new class without breaking your old code)
Think about the contracts your code must live up to. That will drive the interface. If you are scraping a particular type of data (say, sports scores for a given day), those should drive the types of operations available (i.e. function getSportsScoresForDate(date toGet))
Start with your most abstract/general operations at a top level interface, then use other interfaces that extend that interface. This allows users to have interfaces at different levels of granularity (i.e. class SensorDataInterface has a method getData(). HeartRateMonitorInterface extends SensorDataInterface and adds getDataForTimeInterval())
Programming languages/environments aside, are there many developers who are using a framework in PHP, ORM and still abide by encapsulation for the DAL/BLL? I'm managing a team of a few developers and am finding that most of the frameworks require me to do daily code inspection because my developers are using the built in ORM.
Right now, I've been using a tool to generate the classes and CRUD myself, with an area for them to write additional queries/functions. What's been happening though, is they are creating vulnerabilities by not doing proper checks on data permission, or allowing the key fields to be manipulated in the form.
Any suggestions, other than get a new team and a new language (I've seen Python/Ruby frameworks have the same issues).
Throwing away a team is never an option: improve it instead!
Arrange security workshops to make them more aware of these issues.
Introduce (or even better: ask them to introduce) code guide lines for better handling these problems (a security-aware hungarian notation or usage of prepared statements are two examples)
Address the short-comings in code reviews - don't blame them for ignoring security, just show the problematic snippets you found and explain that security is very important to [choose one: this project/the customer/your company's reputation/you personally]
Let them do security audits on their own or their peer's code. Let them find out how easy it is to exploit such security flaws.
Find other tools/frameworks that better support your security model. But be warned: this option is very expensive! Your programmers will need to maintain code in the old framework and learn a new one (worst case: they will need to learn a new language along with the new framework)
But basically this is an issue that you have to solve collaboratively with your developers. If you declare war on them, you're bound to lose (regardless of the outcome for the developers.)
To me it sounds like you want to improve coding culture. Have a look at the Rules of Extreme Programming. Maybe you can adopt a few techniques.
Basically, I get the impression there is very little communication right now between the developers and you. I might be just reading that into it, but to me it sounds like the devs are locked in the cellar and you are sitting somewhere else and getting frustrated about them. Change that kind of thinking. You are part of the team.
If your developers are not aware of the vulnerabilities they introduce into the code, consider having weekly code reviews. Let the developers talk about the code they wrote. Let them learn from each other. Make the code collectively owned. Foster learning and constructive criticism.
Remember, there is no I in Team.
May I recommend Nepthali? It's not an ORM, but the framework is designed to force security. I.E. all variables are encoded before output to the screen; unless explicitely defined not too.
It's also fairly lean, having no ORM, etc. so you can plug whichever ORM into it you want. It's pretty nice, actually.
If you want to check if the user has access to property it is another layer other than data access layer. But still there are frameworks where you can override default load functionality and insert your logics after/before loading.
The lightest framework I ve ever worked is db.php (http://dbphp.net, https://github.com/hazardland/db.php). But it is code first object rational mapper. You ll have to define classes than databases\tables will be created according to your classes.
Take a look at \db\table::load method. Every class has its own handler instance of \db\table located in database::tables array. You can override table::load or create individual handlers for tables derived from \db\table class and place them in database::tables.
The only problem is that framework is not fully documented but has very light intuitive code structure and samples.
Another option is to make dal framework by yourself it will take up to 3-4 months for 1 person to make it full functional and powerfull.
I do not have much experience using frameworks or anything so that leaves me with little experience using Models (MVC). I have no interest whatsoever in using a framework at the moment. I am working on a website and I am trying to model some objects but I'm not sure exactly how I should be designing the class.
For instance, right now I have a class with a few public members which can be accessed directly. I have started prototyping some functions (select, delete, update) but I am not sure
If these functions should be static
If these functions should accept parameters or use the class members instead
If these functions should even exist how they do currently
If the entire concept I'm going for is the right thing to do
I can't seem to find any sort of hints on the interwebs as to how to create a model class.
If you're using a factory class then all verbs are usually instance methods and the factory is instantiated with some sort of DB session.
If the verbs are member's of the entity's class select is usually a static method while update is usually an instance method and delete is usually defined both ways (IE: delete(recordID) and entity.delete())
The entire concept is the right thing to do but you're going to do it wrong. Period. Making a scalable model like this takes a lot more time and effort than people have at their disposal. I know you have no interest in using a framework but you should.
My inference from your question is that this is a low profile project, and you have enough flexibility from your boss/client/teacher that you can build it however you want. That in mind, here is what I would think about when working on this.
If MVC is a new concept to you, then Test-Driven Development is almost certainly and alien one as well. However, I first cracked into a real understanding of OOP while doing it, so I suggest you give it a try. Writing some simple unit tests first against your model classes will take you through the exercise of figuring out how those model classes are going to be used. You'll be working with the external API of each of those objects (or groups of objects if you're not a TDD purist), and that will help guide the design of the internals. Check out PHPUnit for getting started, as the documentation has some great examples as well.
I think the TDD approach will lead you to the following conclusions:
Probably not. Static data/methods are usually only useful when you absolutely need one copy of something. I find in web apps that aside from maybe a resource connection like the DB this is rarely the case.
This depends on what the function does. Keep in mind that using local variables implies side-effects, or changes in the state of the object. If the data you need to operate on should not change the state of the entire object, use a parameter and return a value. It's also easier to test these kinds of methods.
Again, writing tests for these functions that illustrate how you'll use them in the application will lead you to a conclusion one way or another about whether you need them or whether they are designed correctly. Don't be afraid to change them.
Absolutely. How else are you going to become comfortable with MVC if you don't roll your own implementation at least once? In fact, it's probably better to grasp the concepts with real experience before you move to a more professional framework. That way, you'll understand why the concepts and conventions of the framework are the way they are.
Oh, and the lack of clarity that you're finding on what a model class is, is probably due to the fact that it's the part of your application that is most customized. This is your data model and domain logic, so a lot of it is case-specific. The best resource, though, IMHO is Martin Fowler, whose excellent book Patterns of Enterprise Application Architecture goes into a lot of detail on how and why to design a particular set of "model" classes with one pattern or another. Here is the online pattern library--obviously the book is more detailed.
Hope that helps somewhat.
When using PHP, I think designing object oriented model adds extra work with little benefits - even when looking on large frameworks, it's common to just use assoc-arrays that you can get from resultsets (see f.ex. the multiparadigm approach of Zend MVC).
While Object-Relational mapping is much more established among strongly typed languages like Java, there are already tools for PHP as well (f.ex. Doctrine). You may check it out if having OO-oriented model is what you want, but be aware that OR-mapping has severe issues of it's own and might be of little use in PHP (haven't tried it myself in a dynamic language yet).
For most newly started project, picking a good framework is usually a way to go - it can save you time and promote best practices (of course after some learning time that's different for every tool out there). When using some framework, you should always try to find out the framework's / community approach to solving specific problems (like model design & data access) before experimenting on your own.
The "correct" way to abstract away data access using object-oriented concepts is a hot-button topic for a lot of people. Put another way, there are several ways to do it and there is no "one right" way.
Rolling your own works best if you are seriously upgrading an existing application. This is because you have a heap of code that is already database dependant and you have some bounds for the necessary refactoring. It also teaches you about abstracting code because a lot of refactoring involves removing (or reducing) code duplication. Once you've done this to completion, you will have a much better idea of how a data model layer should work. Or at least, should work for the way you program. And you will know what not to do next time you build one. :-)
If you're starting a new codebase and haven't worked with a framework or object layer but know you need to build one, then the best advice I can give is to be willing to build one later, and refactor the code to suit when that does happen. Yes, it will likely mean your application will get 90% rewritten a few times.
Writing an object abstraction layer is difficult and you will end up with dense code that is fairly defensive about things, and doesn't take chances. But once you've got it working, you will also know how to build robust code, because it will probably be debugged fairly thoroughly.
No because, static methods are hard to test
It depends of the parameter, life cycle, etc. Impossible to answer without seeing some code.
?
No
OOP requires at least 10 years of experience to have a better view on what is wrong/right/better/worse.
So, if you are not a OOP expert, instead of losing too much time reinventing the wheel, I would suggest:
Use a well-known framework for the technical part
Create your classes/framework for the business/functional part.
(1) Will help you be ready in no time for the classic technical part (Session, database interaction, etc.). Will avoid you to make errors others already did.
(2) This is your core business, it should be "your DNA".
Also, using a well-known/good technical framework will make you read quality code and help you progress. (Be carefull some frameworks are really of poor quality)
When you will have enough experience, you will be able to skip the technical framework part and build/customize your own... because technical framework are usually evil (They serve too many purposes). :)
I'm trying to design a solid server side architecture and came up with this :
http://www.monsterup.com/image.php?url=upload/1235488072.jpg
The client side only talks to a single server file called process.php, where user rights are checked; and where the action is being dispatched. The business classes then handle the business logic and perform data validation. They all have contain a DataAccessObject class that performs the db operations.
Could you point the different weaknesses such an architecture may have? As far as security, flexibility, extensiveness, ...?
Your architecture isn't perfect. It never will be perfect. Ever. Being perfect is impossible. This is the nature of application development, programming, and the world in general. A requirement will come in to add a feature, or change your business logic and you'll return to this architecture and say "What in the world was I thinking this is terrible." (Hopefully... otherwise you probably haven't been learning anything new!)
Take an inventory of your goals, should it be:
this architecture perfect
or instead:
this architecture functions where I need it to and allows me to get stuff done
One way that you could improve this is to add a view layer, using a template engine such as Smarty, or even roll-your-own. The action classes would prepare the data, assign it to the template, then display the template itself.
That would help you to separate your business logic from your HTML, making it easier to maintain.
This is a common way to design an application.
Another thing you could do is have another class handle the action delegation. It really depends on the complexity of your application, though.
The book PHP Objects, Patterns and Practice can give you a real leg-up on application architecture.
I see a couple of things.
First, I agree with others that you should add a view layer of some kind, though I am not sure about Smarty (I use it frequently and I am really having doubts these days, but I digress). The point is you need to separate your HTML somewhere in a template so it's easy to change. That point does not waver if you use a lot of AJAX. AJAX still requires you (usually) to put divs around the page, etc. So your layout should be separated from processing code.
The second thing I would throw out there is the complexity of your data model matters. If this is a straightforward CRUD application over an existing, or fairly flat, db model, you are probably fine with these db access classes. But, the minute your model gets to be more complex, with hierarchies or polymorphic in any way, this will break down. You'll need a more robust ORM of some kind.
Your "controller/dispatcher" methodology seems sound. The switch statements avoids the need for any kind of URL -> code mappings, which are a pain to manage and require caching to scale.
That's my $0.02
From a security perspective your class and action are coming in from your post variables and this can be dangerous because you should never trust anything coming from the user. Assumingly your class/action will look something like this:
class1
{
action1.1
action1.2
...
action1.N
}
class2
{
action2.1
action2.2
...
action2.N
}
As an attacker my first place to look would be getting into a state where an action doesn't match to it's appropriate class. I would try to submit class1 with action2.1 instead of action1.1.
With that said, my assumption is that you've already got some form of validation and so this wouldn't happen. Which leads me to my original post: If your architecture works for you, then it works for you. Take a look at the things which you're asking about: security, flexibility, extensibility and evaluate them yourself. Find your own flaws. If you don't know how to evaluate for security/flexibility/other read up on the subject, practice it and apply it.
You'll become a better developer by making mistakes and then learning from them (except missile guidance software, you only get one try there.)
Since others have suggested various changes like adding a view layer, etc. let me concentrate on the various criteria for a good architecture:
Extensibility: Usually, the more abstract and loosely coupled the architecture is, the more extensible it is. This is exactly why others have recommended you use a view layer which would abstract out the presentation layer templates for each class:action pair into its own file.
Maintainability: This goes hand-in-hand with extensibility. Generally, the more extensible the architecture is, the more maintainable it is (take that with a grain of salt because it is not always the case). Consider adding a model layer below your model logic layer. This would help you swap out your data access logic from the model business logic.
Security: The downside to the architecture you have posed is that you really need to invest in security testing. Since all your redirecting/routing code is in process.php, that file has a lot of responsibility and any changes to it may result in a potential security loophole. This isn't necessarily wrong, you just need to be aware of the risks.
Scalability: Your architecture is balanced and seems very scalable. Since you have it broken down by class:actions, you can add caching at any layer to improve performance. Adding an addition data access model layer will also help you cache at the layer closest to the database.
Finally, experiment with each architecture and don't be afraid to make mistakes. It already seems like you have a good understanding of MVC. The only way to get better at architecting is to implement and test it in the 'real world'.