<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Odd Christer Brovig's Blog &#187; web development</title>
	<atom:link href="http://www.brovig.org/blog/category/web-development/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.brovig.org/blog</link>
	<description>random thoughts on everything and nothing</description>
	<lastBuildDate>Sat, 13 Dec 2008 23:53:27 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
		<item>
		<title>Lessons Learnt After Developing a Web Application &#8211; Coding</title>
		<link>http://www.brovig.org/blog/2007/05/28/lessons-learnt-after-developing-a-web-application-coding/</link>
		<comments>http://www.brovig.org/blog/2007/05/28/lessons-learnt-after-developing-a-web-application-coding/#comments</comments>
		<pubDate>Mon, 28 May 2007 09:55:44 +0000</pubDate>
		<dc:creator>Odd Christer Brovig</dc:creator>
				<category><![CDATA[web development]]></category>

		<guid isPermaLink="false">http://www.brovig.org/blog/2007/05/28/lessons-learnt-after-developing-a-web-application-coding/</guid>
		<description><![CDATA[Yesterday I talked about how the project was executed in both the design and implementation phase. Today I&#8217;m ranting a bit more in detail about how we coded the thing in PHP (v5). Database Access Our Approach When coding started, we agreed on (or rather, I pushed the view) that we should use the DAO [...]]]></description>
			<content:encoded><![CDATA[<p>Yesterday I talked about how the project was executed in both the design and implementation phase. Today I&#8217;m ranting a bit more in detail about how we coded the thing in PHP (v5).</p>
<h3>Database Access</h3>
<h4>Our Approach</h4>
<p>When coding started, we agreed on (or rather, I pushed the view) that we should use the <a href="http://en.wikipedia.org/wiki/Data_Access_Object" title="Data Access Object">DAO</a> pattern for our database access needs. To work easily with the database, and also to have the possibility of prepared statement we used <a href="http://creole.phpdb.org/trac/">Creole</a>, a PHP database API that&#8217;s very similar to Java&#8217;s.</p>
<p>Soon, we had our DAOs. Though, all was not good. Eager to get going we started coding using our new functionality and didn&#8217;t bother coding up the corresponding <a href="http://www.martinfowler.com/eaaCatalog/serviceLayer.html" title="P of EAA - Service Layer">service layer</a> for them. This was alright to begin with since the application only had some basic CRUD functionality. The problems (or future problems if you want..) became obvious when we started adding functionality that cut across the model objects. Code cutting across the DAO layer was made. And this in turn led to duplicated code. </p>
<p>At that point, I guesstimate that our application was ~70% done. So, to go back and change everything into using a Service Layer wasn&#8217;t an option with the deadline closing up and the code was delivered with those nice dependencies within the layer.</p>
<h4>Alternative Approaches</h4>
<p>Looking back, I see that the <a href="http://www.martinfowler.com/eaaCatalog/activeRecord.html">Active</a> <a href="http://en.wikipedia.org/wiki/Active_record_pattern">Record</a> pattern probably could have been a good choice. </p>
<h3>The View (and Controller)</h3>
<p>This was probably the hardest part to get done right. And there&#8217;s no real consistency in the approach here.</p>
<p>Some places the code for handling form data and get requests were in the same file, and the page posted to itself. I guess this is fine for smaller scripts, but some of ours were starting to get big quick, and  doesn&#8217;t look very maintainable.. In other places there was sort of a controller. They took POST data and redirected with a header(&#8220;Location: foo&#8221;) call. This is a much more maintainable approach, and very MVC.</p>
<p>I think the issue would have been better solved using perhaps the <a href="http://www.martinfowler.com/eaaCatalog/frontController.html">Front Controller</a> pattern or a good <a href="http://en.wikipedia.org/wiki/Model-view-controller">MVC</a> implementation. Both coupled with a template language such as <a href="http://smarty.php.net/">Smarty</a>.</p>
<h3>Summing up</h3>
<p>Creole was a good experience. We lacked a good approach from the data layer and up. Using a framework like <a href="http://www.cakephp.org/">CakePHP</a> or <a href="http://www.symfony-project.com/">symfoni</a> would probably been the best thing to do.</p>
<p>I think I have learnt a thing or two now.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.brovig.org/blog/2007/05/28/lessons-learnt-after-developing-a-web-application-coding/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>
