Comments on: Web application implementation step 3: Framework vs Methodology

By: Alexander

Alexander — Thu, 30 Apr 2009 20:40:32 +0000

Hello! Great method! Am developing my first web application (a helpdesk solution like eTicket). Your method reminds FDD development framework, but its seems to suit much better for my case.

By: Steve

Steve — Mon, 12 Jan 2009 14:47:30 +0000

good post mate, an interesting read. When I have an idea that I get excited about, i more often than not, find it hard to spend the time on doing the pre-work, and jump straight in and start coding. hence I’ve got a whole lot of unfinished projects.

I’ll spend some time next time and do some of things you’ve suggested, in the order you’ve suggested and I’m sure the time invested will be beneficial and i’ll get it back 10fold when my app’s done in less time and more than that actually completed!
cheers.

By: Thibauld

Thibauld — Tue, 23 Dec 2008 11:40:52 +0000

It is a good point you have here! Indeed, whereas I see the object model as being a pure conceptualization of the business logic of the application, the database model is about how you’ll make your data persist. Thus, it has to take other constraints into account.

Personnally, I don’t elaborate any database model until I have a clear view of the queries that will be needed. Depending on the complexity of the project, it is not necessarily mandatory to wait until you’ve build your object model to find out the needed queries. For average projects, you can ’see’ the needed queries from the “wireframing” step in my opinion… once we know the screens to be developed, we can infer the related queries and create a database model accordingly.

But the conclusion stays the same, that is, object model and database model are distinct models. Thanks for pointing this out!

By: David Thomas Garcia

David Thomas Garcia — Mon, 22 Dec 2008 23:44:27 +0000

Great post, I like how you laid out the process for others to follow. I’m not sure what the English word for “maquetter” is, maybe “sketching” or something similar.

One ah-ha moment I had some time ago was when a fellow programmer pointed out that I should considering building the model before thinking about database tables. Because I had always gone from paper prototype to database to coding the object model. But if you instead do the object model before the database it turns out the optimal database might not perfectly reflect the object model.

This is because the object model should be based on object relations. When someone does the database first, the object model might end up reflecting table relations. For simple web sites there is no difference. But when you get into complicated models that involve design patterns especially, the database relations might not reflect the object relations perfectly any more.

Once I started thinking in this manner, I noticed how much easier it is to write my object model then make an optimized database to persist that model. When I did database first, I kept having to go back and change the database schema as my object model took shape in the coding stage.