Thoughts on w̶̶e̶̶b̶ application development
> “How you build your application, it is not the tools you use.” This quote is result of discussions with other developers. Every time the “how you build your application?” question drops, I get answers like “we use $x framework”, “$y database" in some rare cases “we do tdd” is between the answers. I will stand in the framework as it is considered to be main library to build your application. And since MVC is the monopoly out there ##Model, View Controller. Lets rethink about it for a minute, shall we?! ##Model There is a misconception that Active Record is the Model. So what is Active Record if not the model of the application: > The interface of an Active Record object would include functions such as Insert, Update, and Delete, plus properties that correspond more or less directly to the columns in the underlying database table. Using an active record as you model, dominate the shape of your code. Now the persistence logic is all over your application code. In the case of an application a model would be a Beer object. If I asked you to create a Beer Class would you ever thought about a function name like save(), insert(). But your code is bloated and you end up having the database in the middle of your application, this make transition to other type of persistence more hard. There other patterns out there... Before moving on a note on the Beer object we mentioned before. A Beer object has different values and functionality based on the place it belongs example: in the factory, during the transportation and finally at a bar. ##Controller Controller here is to define the context. Based of context he uses the appropriate models. Its use case, a scenario. Its not Create Read Update Delete. Who is talking to your application controller? A Mobile Client A Desktop Client A Web Client ... a.k.a. a browser. Since we are talking about web let’s be clear about it. There is no such thing as a “user” in your application. Your web/mobile/desktop client may have a user but your application only accepts requests to do magic. Parameters of your request should state if the action should be done or not. /myBasket/view /basket/41491/view?customer_id=1943&secret=? The request and the result have 1-1 relation. The same url must always give the same result no matter what. Hints: Reverse caching. This same result should be predictable this mean your controller should be testable. It’s is an object in the of the day isn’t it ? And the http protocol it is just a detail. ##View Speaking of results, what a result could be except a representation of your application models in variety of states during their lifecircle. A view of your application should not contain html. Html is used by browser to render a web page. Your models data may appear on that page but they are not the page. You can always use XML if you like tags or if your web client needs to navigate with xpath. What is the tricky part in a view like more than encoding my objects to json? Your applications navigation. Your clients should be ignorant about your applications urls. Every response from your application should contain paths to related application calls the same way a web site provide links to related resources.
