What is the Best Workflow for Web Application?

Question

I am about to begin a web application. Before I begin, I would like to get some advice as to what the best work flow/order is for creating a web application such as this.

My project will consist of a server-side with PHP and MySQL. The client-side will be XHtml, CSS and jQuery. There will also be AJAX used.

I'm sure that it can depend on certain situations, but, overall, what is the best order for developing a project with these credentials?

Should I start developing the server-side first? Or should I begin with the client-side? Or should I do both at the same time? What about the database - should that be a first priority? Then perhaps the DAOs?

Answer 1

Start with the data first. The server-side data is the persistent, essential core of the application. If this data model isn't right, you have nothing.

You should be able to unit test the data model to prove that you have the right attributes and relationships. This doesn't require much. A few test cases to insert, update and query.

You will support that data model with back-end processing.

This, too, should be unit tested to demonstrate that it works and does all the right things to your data model. This will be a bit more complex, since this processing is the application.

Then you can think about the data model as exposed by web services to Ajax.

This, also, is testable to prove that the JSON does the right things. This testing is often fairly complex because this is what the GUI front-end relies on. This has to be right.

Then, once you have that Ajax data model worked out, you can write the front-end GUI.

Answer 2

The workflow you're describing is what I use for my own (solo) projects.

I like to meet in the middle. I do data modeling first, and simultaneously start prototyping the interface. Business rules come last and pull everything together.

I also find it "inspiring" when I have a GUI to look at... it encourages me to make it do something. Furthermore, GUI's tend to undergo the most revising, so starting them early in the process ensures you'll be happy with the finished product, and that it'll be finalized by the time your business logic is implemented.

Answer 3

If I'm working for a big company that's not sure of exactly what they want, I'll start with the UI first. This way they get to figure out what they want before I've put a lot of time into the rest of the system.

On the other hand, if I know exactly what is needed, then I will start with one feature and work my way up through the layers, database, controller, view, and ajax, until that feature is done, and then go on to the next feature. This way I've got less context to remember, and the client always has something new to play with.

Answer 4

I can't tell you what's absolutely best, but what works for me is...

• Talk to the business people to get an idea of what they want.

• Draw the UI with pen and paper. Boxes represent pages. Buttons and links have arrows pointing to other pages. Don't need every microscopic detail. Some things are implicit.

• Once the UI is mapped out pretty well, design the DB schema. Sometimes I'll write out all the tables in a text file like this...

---

pets
----
id
name
species
# etc...

---

• Then implement the database. I use Rails migrations. You might write the DDL manually.

• If you have models or DAOs or something along those lines I would implement those next, with unit tests.

• Then I usually work through the app entity by entity. Get the view and controllers working. Rapidly switching between the testing code and the implementation code.

That's the general sequence, but the whole time there are adjustments and so on. You'll need to go back to your DB design and evolve that as you build the actual functionality.