Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I have been coding small to medium size applications for several years now, mostly business applications or database-driven applications, In each new project i feel tempted to start with the database design and then write the code that sends/retrieves data to/from the database, MVC frameworks are really helpful to organize my code for web applications. But that's it for me.

I could argue that any application is more or less the same, stores and retrieves data. And i think having a good database design makes the job a lot easier, So what else do i need? And why? Any examples?

I am trying to improve my skills and knowledge to be able to handle bigger projects, I find OOP, OOAD and software design/architecture really interesting, but i don't know why on earth i would need them in data-driven applications (i know it's me!), I find a lot of articles talk about design patterens, business objects, serive layers, architecture and more, but when i think of any new application, it's always the same, I have a good database design and then i am ready to go, if the client needs more feature, i modify the database strucutre or add new tables/views , add new screens/web pages then i am done. What is wrong with that approach?

For instance, there was a directory web application i was asked to do, i thought of designing the objects first then converting them into a database structure using ORM, but i found it time consuming, i wondered why i had to design both the objects and the data, and i went for my old approach to save time and effort.

I know it's me, I know I am mistaken, but i think having more layers or tiers between the GUI and database is an extra effort and extra time, so when does it matter? When is it worth it? so i am asking: What is the use of OOP in developing business/database applications? Any example would be appreciated

In other words When do i have to separately design both the objects and the database schema? and what are the benifits? Any example??


share|improve this question

closed as too broad by GlenH7, Robert Harvey, MichaelT, gnat, Doc Brown Feb 22 '14 at 8:05

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs. If this question can be reworded to fit the rules in the help center, please edit the question.

If the only tool you have is a hammer, then the world appears to you as a nail. If all you have done is essentially the same application over and over again, then all applications appear the same. Your question is heavily biased by the (lack of) experience(s) that you have had with programming. –  GlenH7 Feb 21 '14 at 23:00
@GlenH7 I admit it already, I would appreciate an objective answer. –  Akram Hassan Feb 21 '14 at 23:04
I have voted to close as too broad. "What is the use of modern software design topics in developing business/database applications?" has been written about many times (as you mentioned) and the topic could easily fill multiple books. –  GlenH7 Feb 21 '14 at 23:13
I added more details and narrowed down the question, hope it helps to find better answers to my important inquiries, your interest would be appreciated. –  Akram Hassan Feb 24 '14 at 18:49

2 Answers 2

What is the use of modern software design topics in developing business/database applications?

Well, put simply, their use is to solve the problems they were designed to solve.

I know that's not a very satisfying answer, but GlenH7's comment has got it right. Your question is loaded with bias, and here's why:

These "design topics" are known solutions to real problems. From your question it looks like you have yet to find one of these problems in your career, so you find it hard to understand the use of a solution. But this is false.

You have encountered these problems but just haven't noticed them. Your current approach to developing software is preventing you from seeing the bigger picture. This is the bias GlenH7 was talking about.

By reading about these "modern design topics" you will learn to see the bigger picture. This will allow you better identify these problems, and to better identify their solutions.

In other words, this will extend you tool set far beyond the simple hammer.

share|improve this answer
any objective examples? –  Akram Hassan Feb 21 '14 at 23:23

As has been mentioned, a large part of your confusion stems from experience bias. If you haven't encountered a problem before, then the corresponding solution seems redundant, unnecessary, or fundamentally flawed. Once you've encountered it, and utilized the solution in question, you'll often be able to reflect back and it and see precisely how applicable it was to the situation at hand.

I'll admit that I only skimmed the beginning of this paper, but it seems particularly applicable to your question and contains some pertinent examples: An approach to precisely specifying the problem domain of design patterns.

From the intro of the paper:

A design pattern encapsulates a proven solution for a class of recurring design problems. Use of design patterns in software development often results in high quality product. In general, design patterns are used during the design phase, and using the right patterns for a given problem becomes an important decision which directly impacts the implementation and the overall quality of the software. A question which naturally arises is, how to determine the right pattern? One answer would be to use the problem domain of patterns.

Hopefully this helps.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.