Patterns of Enterprise Application Architecture

Martin Fowler

Mentioned 173

This volume is a handbook for enterprise system developers, guiding them through the intricacies and lessons learned in enterprise application development. It provides proven solutions to the everyday problems facing information systems developers.

More on

Mentioned in questions and answers.

If you could go back in time and tell yourself to read a specific book at the beginning of your career as a developer, which book would it be?

I expect this list to be varied and to cover a wide range of things.

To search: Use the search box in the upper-right corner. To search the answers of the current question, use inquestion:this. For example:

inquestion:this "Code Complete"

Applying UML and Patterns by Craig Larman.

The title of the book is slightly misleading; it does deal with UML and patterns, but it covers so much more. The subtitle of the book tells you a bit more: An Introduction to Object-Oriented Analysis and Design and Iterative Development.

Masters of doom. As far as motivation and love for your profession go: it won't get any better than what's been described in this book, truthfully inspiring story!

Beginning C# 3.0: An Introduction to Object Oriented Programming

This is the book for those who want to understand the whys and hows of OOP using C# 3.0. You don't want to miss it.

alt text

Mastery: The Keys to Success and Long-Term Fulfillment, by George Leonard

It's about about what mindsets are required to reach mastery in any skill, and why. It's just awesome, and an easy read too.

Pro Spring is a superb introduction to the world of Inversion of Control and Dependency Injection. If you're not aware of these practices and their implications - the balance of topics and technical detail in Pro Spring is excellent. It builds a great case and consequent personal foundation.

Another book I'd suggest would be Robert Martin's Agile Software Development (ASD). Code smells, agile techniques, test driven dev, principles ... a well-written balance of many different programming facets.

More traditional classics would include the infamous GoF Design Patterns, Bertrand Meyer's Object Oriented Software Construction, Booch's Object Oriented Analysis and Design, Scott Meyer's "Effective C++'" series and a lesser known book I enjoyed by Gunderloy, Coder to Developer.

And while books are nice ... don't forget radio!

... let me add one more thing. If you haven't already discovered safari - take a look. It is more addictive than stack overflow :-) I've found that with my google type habits - I need the more expensive subscription so I can look at any book at any time - but I'd recommend the trial to anyone even remotely interested.

(ah yes, a little obj-C today, cocoa tomorrow, patterns? soa? what was that example in that cookbook? What did Steve say in the second edition? Should I buy this book? ... a subscription like this is great if you'd like some continuity and context to what you're googling ...)

Database System Concepts is one of the best books you can read on understanding good database design principles.

alt text

Algorithms in C++ was invaluable to me in learning Big O notation and the ins and outs of the various sort algorithms. This was published before Sedgewick decided he could make more money by dividing it into 5 different books.

C++ FAQs is an amazing book that really shows you what you should and shouldn't be doing in C++. The backward compatibility of C++ leaves a lot of landmines about and this book helps one carefully avoid them while at the same time being a good introduction into OO design and intent.

Here are two I haven't seen mentioned:
I wish I had read "Ruminations on C++" by Koenig and Moo much sooner. That was the book that made OO concepts really click for me.
And I recommend Michael Abrash's "Zen of Code Optimization" for anyone else planning on starting a programming career in the mid 90s.

Perfect Software: And Other Illusions about Testing


Perfect Software: And Other Illusions about Testing by Gerald M. Weinberg

ISBN-10: 0932633692

ISBN-13: 978-0932633699

Rapid Development by McConnell

The most influential programming book for me was Enough Rope to Shoot Yourself in the Foot by Allen Holub.

Cover of the book

O, well, how long ago it was.

I have a few good books that strongly influenced me that I've not seen on this list so far:

The Psychology of Everyday Things by Donald Norman. The general principles of design for other people. This may seem to be mostly good for UI but if you think about it, it has applications almost anywhere there is an interface that someone besides the original developer has to work with; e. g. an API and designing the interface in such a way that other developers form the correct mental model and get appropriate feedback from the API itself.

The Art of Software Testing by Glen Myers. A good, general introduction to testing software; good for programmers to read to help them think like a tester i. e. think of what may go wrong and prepare for it.

By the way, I realize the question was the "Single Most Influential Book" but the discussion seems to have changed to listing good books for developers to read so I hope I can be forgiven for listing two good books rather than just one.

alt text

C++ How to Program It is good for beginner.This is excellent book that full complete with 1500 pages.

Effective C++ and More Effective C++ by Scott Myers.

Inside the C++ object model by Stanley Lippman

I bough this when I was a complete newbie and took me from only knowing that Java existed to a reliable team member in a short time

Not a programming book, but still a very important book every programmer should read:

Orbiting the Giant Hairball by Gordon MacKenzie

The Pragmatic programmer was pretty good. However one that really made an impact when I was starting out was :

Windows 95 System Programming Secrets"

I know - it sounds and looks a bit cheesy on the outside and has probably dated a bit - but this was an awesome explanation of the internals of Win95 based on the Authors (Matt Pietrek) investigations using his own own tools - the code for which came with the book. Bear in mind this was before the whole open source thing and Microsoft was still pretty cagey about releasing documentation of internals - let alone source. There was some quote in there like "If you are working through some problem and hit some sticking point then you need to stop and really look deeply into that piece and really understand how it works". I've found this to be pretty good advice - particularly these days when you often have the source for a library and can go take a look. Its also inspired me to enjoy diving into the internals of how systems work, something that has proven invaluable over the course of my career.

Oh and I'd also throw in effective .net - great internals explanation of .Net from Don Box.

I recently read Dreaming in Code and found it to be an interesting read. Perhaps more so since the day I started reading it Chandler 1.0 was released. Reading about the growing pains and mistakes of a project team of talented people trying to "change the world" gives you a lot to learn from. Also Scott brings up a lot of programmer lore and wisdom in between that's just an entertaining read.

Beautiful Code had one or two things that made me think differently, particularly the chapter on top down operator precedence.


@Juan: I know Juan, I know - but there are some things that can only be learned by actually getting down to the task at hand. Speaking in abstract ideals all day simply makes you into an academic. It's in the application of the abstract that we truly grok the reason for their existence. :P

@Keith: Great mention of "The Inmates are Running the Asylum" by Alan Cooper - an eye opener for certain, any developer that has worked with me since I read that book has heard me mention the ideas it espouses. +1

I found the The Algorithm Design Manual to be a very beneficial read. I also highly recommend Programming Pearls.

This one isnt really a book for the beginning programmer, but if you're looking for SOA design books, then SOA in Practice: The Art of Distributed System Design is for you.

For me it was Design Patterns Explained it provided an 'Oh that's how it works' moment for me in regards to design patterns and has been very useful when teaching design patterns to others.

Code Craft by Pete Goodliffe is a good read!

Code Craft

The first book that made a real impact on me was Mastering Turbo Assembler by Tom Swan.

Other books that have had an impact was Just For Fun by Linus Torvalds and David Diamond and of course The Pragmatic Programmer by Andrew Hunt and David Thomas.

In addition to other people's suggestions, I'd recommend either acquiring a copy of SICP, or reading it online. It's one of the few books that I've read that I feel greatly increased my skill in designing software, particularly in creating good abstraction layers.

A book that is not directly related to programming, but is also a good read for programmers (IMO) is Concrete Mathematics. Most, if not all of the topics in it are useful for programmers to know about, and it does a better job of explaining things than any other math book I've read to date.

For me "Memory as a programming concept in C and C++" really opened my eyes to how memory management really works. If you're a C or C++ developer I consider it a must read. You will defiantly learn something or remember things you might have forgotten along the way.

Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.

I used this book as the starting point to understanding Agile development.

Systemantics: How Systems Work and Especially How They Fail. Get it used cheap. But you might not get the humor until you've worked on a few failed projects.

The beauty of the book is the copyright year.

Probably the most profound takeaway "law" presented in the book:

The Fundamental Failure-Mode Theorem (F.F.T.): Complex systems usually operate in failure mode.

The idea being that there are failing parts in any given piece of software that are masked by failures in other parts or by validations in other parts. See a real-world example at the Therac-25 radiation machine, whose software flaws were masked by hardware failsafes. When the hardware failsafes were removed, the software race condition that had gone undetected all those years resulted in the machine killing 3 people.

It seems most people have already touched on the some very good books. One which really helped me out was Effective C#: 50 Ways to Improve your C#. I'd be remiss if I didn't mention The Tao of Pooh. Philosophy books can be good for the soul, and the code.

Discrete Mathematics For Computer Scientists

Discrete Mathematics For Computer Scientists by J.K. Truss.

While this doesn't teach you programming, it teaches you fundamental mathematics that every programmer should know. You may remember this stuff from university, but really, doing predicate logic will improve you programming skills, you need to learn Set Theory if you want to program using collections.

There really is a lot of interesting information in here that can get you thinking about problems in different ways. It's handy to have, just to pick up once in a while to learn something new.

I saw a review of Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools on a blog talking also about XI-Factory, I read it and I must say this book is a must read. Altough not specifically targetted to programmers, it explains very clearly what is happening in the programming world right now with Model-Driven Architecture and so on..

Solid Code Optimizing the Software Development Life Cycle

Although the book is only 300 pages and favors Microsoft technologies it still offers some good language agnostic tidbits.

Managing Gigabytes is an instant classic for thinking about the heavy lifting of information.

My vote is "How to Think Like a Computer Scientist: Learning With Python" It's available both as a book and as a free e-book.

It really helped me to understand the basics of not just Python but programming in general. Although it uses Python to demonstrate concepts, they apply to most, if not all, programming languages. Also: IT'S FREE!

Object-Oriented Programming in Turbo C++. Not super popular, but it was the one that got me started, and was the first book that really helped me grok what an object was. Read this one waaaay back in high school. It sort of brings a tear to my eye...

My high school math teacher lent me a copy of Are Your Lights Figure Problem that I have re-read many times. It has been invaluable, as a developer, and in life generally.

I'm reading now Agile Software Development, Principles, Patterns and Practices. For those interested in XP and Object-Oriented Design, this is a classic reading.

alt text

Kernighan & Plauger's Elements of Programming Style. It illustrates the difference between gimmicky-clever and elegant-clever.

to get advanced in prolog i like these two books:

The Art of Prolog

The Craft of Prolog

really opens the mind for logic programming and recursion schemes.

Here's an excellent book that is not as widely applauded, but is full of deep insight: Agile Software Development: The Cooperative Game, by Alistair Cockburn.

What's so special about it? Well, clearly everyone has heard the term "Agile", and it seems most are believers these days. Whether you believe or not, though, there are some deep principles behind why the Agile movement exists. This book uncovers and articulates these principles in a precise, scientific way. Some of the principles are (btw, these are my words, not Alistair's):

  1. The hardest thing about team software development is getting everyone's brains to have the same understanding. We are building huge, elaborate, complex systems which are invisible in the tangible world. The better you are at getting more peoples' brains to share deeper understanding, the more effective your team will be at software development. This is the underlying reason that pair programming makes sense. Most people dismiss it (and I did too initially), but with this principle in mind I highly recommend that you give it another shot. You wind up with TWO people who deeply understand the subsystem you just built ... there aren't many other ways to get such a deep information transfer so quickly. It is like a Vulcan mind meld.
  2. You don't always need words to communicate deep understanding quickly. And a corollary: too many words, and you exceed the listener/reader's capacity, meaning the understanding transfer you're attempting does not happen. Consider that children learn how to speak language by being "immersed" and "absorbing". Not just language either ... he gives the example of some kids playing with trains on the floor. Along comes another kid who has never even SEEN a train before ... but by watching the other kids, he picks up the gist of the game and plays right along. This happens all the time between humans. This along with the corollary about too many words helps you see how misguided it was in the old "waterfall" days to try to write 700 page detailed requirements specifications.

There is so much more in there too. I'll shut up now, but I HIGHLY recommend this book!

alt text

The Back of the Napkin, by Dan Roam.

The Back of the Napkin

A great book about visual thinking techniques. There is also an expanded edition now. I can't speak to that version, as I do not own it; yet.

Agile Software Development by Alistair Cockburn

Do users ever touch your code? If you're not doing solely back-end work, I recommend About Face: The Essentials of User Interface Design — now in its third edition (linked). I used to think my users were stupid because they didn't "get" my interfaces. I was, of course, wrong. About Face turned me around.

"Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C Programs (Microsoft Programming Series)" by Steve MacGuire.

Interesting what a large proportion the books mentioned here are C/C++ books.

While not strictly a software development book, I would highly recommend that Don't Make me Think! be considered in this list.

As so many people have listed Head First Design Patterns, which I agree is a very good book, I would like to see if so many people aware of a title called Design Patterns Explained: A New Perspective on Object-Oriented Design.

This title deals with design patterns excellently. The first half of the book is very accessible and the remaining chapters require only a firm grasp of the content already covered The reason I feel the second half of the book is less accessible is that it covers patterns that I, as a young developer admittedly lacking in experience, have not used much.

This title also introduces the concept behind design patterns, covering Christopher Alexander's initial work in architecture to the GoF first implementing documenting patterns in SmallTalk.

I think that anyone who enjoyed Head First Design Patterns but still finds the GoF very dry, should look into Design Patterns Explained as a much more readable (although not quite as comprehensive) alternative.

Even though i've never programmed a game this book helped me understand a lot of things in a fun way.

How influential a book is often depends on the reader and where they were in their career when they read the book. I have to give a shout-out to Head First Design Patterns. Great book and the very creative way it's written should be used as an example for other tech book writers. I.e. it's written in order to facilitate learning and internalizing the concepts.

Head First Design Patterns

97 Things Every Programmer Should Know

alt text

This book pools together the collective experiences of some of the world's best programmers. It is a must read.

Extreme Programming Explained: Embrace Change by Kent Beck. While I don't advocate a hardcore XP-or-the-highway take on software development, I wish I had been introduced to the principles in this book much earlier in my career. Unit testing, refactoring, simplicity, continuous integration, cost/time/quality/scope - these changed the way I looked at development. Before Agile, it was all about the debugger and fear of change requests. After Agile, those demons did not loom as large.

One of my personal favorites is Hacker's Delight, because it was as much fun to read as it was educational.

I hope the second edition will be released soon!

You.Next(): Move Your Software Development Career to the Leadership Track ~ Michael C. Finley (Author), Honza Fedák (Author) link text

I've been arounda while, so most books that I have found influential don't necessarily apply today. I do believe it is universally important to understand the platform that you are developing for (both hardware and OS). I also think it's important to learn from other peoples mistakes. So two books I would recommend are:

Computing Calamities and In Search of Stupidity: Over Twenty Years of High Tech Marketing Disasters

Working Effectively with Legacy Code is a really amazing book that goes into great detail about how to properly unit test your code and what the true benefit of it is. It really opened my eyes.

A long time ago I have read an article (I believe a blog entry) which put me on the "right" track on naming objects: Be very very scrupulous about naming things in your program.

For example if my application was (as a typical business app) handling users, companies and addresses I'd have a User, a Company and an Address domain class - and probably somewhere a UserManager, a CompanyManager and an AddressManager would pop up that handles those things.

So can you tell what those UserManager, CompanyManager and AddressManager do? No, because Manager is a very very generic term that fits to anything you can do with your domain objects.

The article I read recommended using very specific names. If it was a C++ application and the UserManager's job was allocating and freeing users from the heap it would not manage the users but guard their birth and death. Hmm, maybe we could call this a UserShepherd.

Or maybe the UserManager's job is to examine each User object's data and sign the data cryptographically. Then we'd have a UserRecordsClerk.

Now that this idea stuck with me I try to apply it. And find this simple idea amazingly hard.

I can describe what the classes do and (as long as I don't slip into quick & dirty coding) the classes I write do exactly one thing. What I miss to go from that description to the names is a kind of catalogue of names, a vocabulary that maps the concepts to names.

Ultimately I'd like to have something like a pattern catalogue in my mind (frequently design patterns easily provide the object names, e.g. a factory)

  • Factory - Creates other objects (naming taken from the design pattern)
  • Shepherd - A shepherd handles the lifetime of objects, their creation and shutdown
  • Synchronizer - Copies data between two or more objects (or object hierarchies)
  • Nanny - Helps objects reach "usable" state after creation - for example by wiring to other objects

  • etc etc.

So, how do you handle that issue? Do you have a fixed vocabulary, do you invent new names on the fly or do you consider naming things not-so-important or wrong?

P.S.: I'm also interested in links to articles and blogs discussing the issue. As a start, here is the original article that got me thinking about it: Naming Java Classes without a 'Manager'

Update: Summary of answers

Here's a little summary of what I learned from this question in the meantime.

  • Try not to create new metaphors (Nanny)
  • Have a look at what other frameworks do

Further articles/books on this topic:

And a current list of name prefixes/suffixes I collected (subjectively!) from the answers:

  • Coordinator
  • Builder
  • Writer
  • Reader
  • Handler
  • Container
  • Protocol
  • Target
  • Converter
  • Controller
  • View
  • Factory
  • Entity
  • Bucket

And a good tip for the road:

Don't get naming paralysis. Yes, names are very important but they're not important enough to waste huge amounts of time on. If you can't think up a good name in 10 minutes, move on.

I asked a similar question but where possible I try to copy the names already in the .NET framework, look for ideas in the Java and Android frameworks.

Seems Helper, Manager, Util is the unavoidable noun you attach for coordinating classes that contain no state and are generally procedural and static. An alternative is Coordinator.

You could get particularly purple prosey with the names and go for things like Minder, Overseer,Supervisor,Administrator,Master but as I said I prefer keeping it like the framework names you're use to.

Some other common suffixes (if that is the correct term) you also find in the .NET framework are

  • Builder
  • Writer
  • Reader
  • Handler
  • Container

Specific to C#, I found "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries" to have lots of good information on the logic of naming.

As far as finding those more specific words though, I often use a thesaurus and jump through related words to try and find a good one. I try not to spend to much time with it though, as I progress through development I come up with better names, or sometimes realize that SuchAndSuchManager should really be broken up into multiple classes, and then the name of that deprecated class becomes a non-issue.

I'm thinking about how to represent a complex structure in a SQL Server database.

Consider an application that needs to store details of a family of objects, which share some attributes, but have many others not common. For example, a commercial insurance package may include liability, motor, property and indemnity cover within the same policy record.

It is trivial to implement this in C#, etc, as you can create a Policy with a collection of Sections, where Section is inherited as required for the various types of cover. However, relational databases don't seem to allow this easily.

I can see that there are two main choices:

  1. Create a Policy table, then a Sections table, with all the fields required, for all possible variations, most of which would be null.

  2. Create a Policy table and numerous Section tables, one for each kind of cover.

Both of these alternatives seem unsatisfactory, especially as it is necessary to write queries across all Sections, which would involve numerous joins, or numerous null-checks.

What is the best practice for this scenario?

@Bill Karwin describes three inheritance models in his SQL Antipatterns book, when proposing solutions to the SQL Entity-Attribute-Value antipattern. This is a brief overview:

Single Table Inheritance (aka Table Per Hierarchy Inheritance):

Using a single table as in your first option is probably the simplest design. As you mentioned, many attributes that are subtype-specific will have to be given a NULL value on rows where these attributes do not apply. With this model, you would have one policies table, which would look something like this:

| id   | date_issued         | type     | vehicle_reg_no | property_address |
|    1 | 2010-08-20 12:00:00 | MOTOR    | 01-A-04004     | NULL             |
|    2 | 2010-08-20 13:00:00 | MOTOR    | 02-B-01010     | NULL             |
|    3 | 2010-08-20 14:00:00 | PROPERTY | NULL           | Oxford Street    |
|    4 | 2010-08-20 15:00:00 | MOTOR    | 03-C-02020     | NULL             |

\------ COMMON FIELDS -------/          \----- SUBTYPE SPECIFIC FIELDS -----/

Keeping the design simple is a plus, but the main problems with this approach are the following:

  • When it comes to adding new subtypes, you would have to alter the table to accommodate the attributes that describe these new objects. This can quickly become problematic when you have many subtypes, or if you plan to add subtypes on a regular basis.

  • The database will not be able to enforce which attributes apply and which don't, since there is no metadata to define which attributes belong to which subtypes.

  • You also cannot enforce NOT NULL on attributes of a subtype that should be mandatory. You would have to handle this in your application, which in general is not ideal.

Concrete Table Inheritance:

Another approach to tackle inheritance is to create a new table for each subtype, repeating all the common attributes in each table. For example:

--// Table: policies_motor
| id   | date_issued         | vehicle_reg_no |
|    1 | 2010-08-20 12:00:00 | 01-A-04004     |
|    2 | 2010-08-20 13:00:00 | 02-B-01010     |
|    3 | 2010-08-20 15:00:00 | 03-C-02020     |

--// Table: policies_property    
| id   | date_issued         | property_address |
|    1 | 2010-08-20 14:00:00 | Oxford Street    |   

This design will basically solve the problems identified for the single table method:

  • Mandatory attributes can now be enforced with NOT NULL.

  • Adding a new subtype requires adding a new table instead of adding columns to an existing one.

  • There is also no risk that an inappropriate attribute is set for a particular subtype, such as the vehicle_reg_no field for a property policy.

  • There is no need for the type attribute as in the single table method. The type is now defined by the metadata: the table name.

However this model also comes with a few disadvantages:

  • The common attributes are mixed with the subtype specific attributes, and there is no easy way to identify them. The database will not know either.

  • When defining the tables, you would have to repeat the common attributes for each subtype table. That's definitely not DRY.

  • Searching for all the policies regardless of the subtype becomes difficult, and would require a bunch of UNIONs.

This is how you would have to query all the policies regardless of the type:

SELECT     date_issued, other_common_fields, 'MOTOR' AS type
FROM       policies_motor
SELECT     date_issued, other_common_fields, 'PROPERTY' AS type
FROM       policies_property;

Note how adding new subtypes would require the above query to be modified with an additional UNION ALL for each subtype. This can easily lead to bugs in your application if this operation is forgotten.

Class Table Inheritance (aka Table Per Type Inheritance):

This is the solution that @David mentions in the other answer. You create a single table for your base class, which includes all the common attributes. Then you would create specific tables for each subtype, whose primary key also serves as a foreign key to the base table. Example:

CREATE TABLE policies (
   policy_id          int,
   date_issued        datetime,

   -- // other common attributes ...

CREATE TABLE policy_motor (
    policy_id         int,
    vehicle_reg_no    varchar(20),

   -- // other attributes specific to motor insurance ...

   FOREIGN KEY (policy_id) REFERENCES policies (policy_id)

CREATE TABLE policy_property (
    policy_id         int,
    property_address  varchar(20),

   -- // other attributes specific to property insurance ...

   FOREIGN KEY (policy_id) REFERENCES policies (policy_id)

This solution solves the problems identified in the other two designs:

  • Mandatory attributes can be enforced with NOT NULL.

  • Adding a new subtype requires adding a new table instead of adding columns to an existing one.

  • No risk that an inappropriate attribute is set for a particular subtype.

  • No need for the type attribute.

  • Now the common attributes are not mixed with the subtype specific attributes anymore.

  • We can stay DRY, finally. There is no need to repeat the common attributes for each subtype table when creating the tables.

  • Managing an auto incrementing id for the policies becomes easier, because this can be handled by the base table, instead of each subtype table generating them independently.

  • Searching for all the policies regardless of the subtype now becomes very easy: No UNIONs needed - just a SELECT * FROM policies.

I consider the class table approach as the most suitable in most situations.

The names of these three models come from Martin Fowler's book Patterns of Enterprise Application Architecture.

I'm a confused newbie and hobbyist programmer trying to get a grip on this, so forgive me if my question is a little off or doesn't make much sense.

I see a lot of questions on SO revolving around the use of design patterns, and I'm wondering if anyone has a good resources for learning about, and implementing design patterns? I understand the general idea, and know how/when to use a couple of them(Singletons, Factory methods) but I know I'm missing out.

(Just in case it matters, my language of preference is C# but I could learn from examples in other languages)

Applying UML and Patterns by Craig Larman. Start from the basic of analysis, design and uses a simple Case scenario. Introduces most of the basic patterns in a simple way.

An introductory book that I found useful and well written is Design Patterns Explained by Alan Shalloway and James Trott (Addison Wesley).

alt text

Do not start from the Gang of Four book, for it is not an introductory book by any means.

The original Design Patterns book is a must-read for all programmers.

It is an excellent book on every level: layout, clarity, insight, depth. It's one of those great books that you first read cover-to-cover, and then use as a reference until you literally know it inside out.

You could start by the Wikipedia page, but treat yourself with the great book too.

Design patterns are great for various reasons:

  1. gives you a starting for solving common problems.
  2. gives developers a vocabulary to talk about certain ways of solving problems in a very compact manner.
  3. when working with developers who know design patterns and you use design patterns in your solutions they will understand the solutions a lot faster.

But when your goal is just to learn design patterns I think you are missing the fundamentals. All design patterns are based on more common principles. High Cohesion, Low Coupling Open Closed Principle, DRY, Liskov Substitution Principle etc. For these fundamentals I would read the following books in this order:

  1. Head First Object-Oriented Analysis and Design (Head First) [ILLUSTRATED] (Paperback)
  2. Applying UML and Patterns (Hardcover)
  3. Agile Principles, Patterns, and Practices in C# (Robert C. Martin Series) (Hardcover)

After that you are ready for the basic gang of four design patterns

  1. Head First Design Patterns (Head First) [ILLUSTRATED] (Paperback)
  2. The BIBLE
  3. A nice website (don't buy anything, it is not worth it) (some implementations of this site are worth a discussion

The next step:

  1. Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series) (Hardcover)
  2. The POSA books

And always remember : the pattern is not the goal !

Before spending money on books I would recommend Wikipedia's excellent design patterns page. Also for something different Google for "design pattern screencasts" or search for "design patterns" on YouTube. Getting the same information presented differently often helps the penny drop.

The Gang of Four book is the definitive text on the most well known patterns but is not that easy to read and with C++ examples not everyone's favourite.

The Head First Design Patterns text is far more accessible but only contains a subset of the Gang of Four patterns.

The most important thing is to understand where and why a particular pattern is useful. Afterwards search the web for implementation examples in the language of your choice and experiment until you "get it". Understand one pattern before moving on to the next. Everyone understands some patterns better than others (and there are hundreds of lesser known ones).

Just keep plugging away.

Head First Design Patterns

alt text

and the Design Pattern Wikipedia page are the best resources for beginners. FluffyCat is another good, free online resource for design patterns in both Java and PHP.

The Gang of Four book is where to go afterward, but it's fairly advanced, so I'd wait until you have a pretty firm grasp from the other resources.

I'd add that Design Patterns book from the "Gang of four" is a bible for anyone who is seriously interested in design patterns.

According to Sun and Msdn it is a design pattern.

According to Wikipedia it is an architectural pattern

In comparison to design patterns, architectural patterns are larger in scale. (Wikipedia - Architectural pattern)

Or it is an architectural pattern that also has a design pattern ?

Which one is true ?

MVC always mentioned and introduced as/in presentation layer in software architecture books.

Read these books:

  1. Architecting Microsoft.NET Solutions for the Enterprise (Microsoft press)

  2. Professional ASP.NET design patterns (Wrox)

  3. Enterpise Solutions Patterns Using Microsoft.NET (Microsoft press)

  4. Patterns of Enterprise Application Architecture (Addison Wesley)

  5. A Practical Guide to Enterprise Architecture (Prentice Hall)

What does the term Plain Old Java Object (POJO) mean? I couldn't find anything explanatory enough.

POJO's Wikipedia page says that POJO is an ordinary Java Object and not a special object. Now, what makes or what doesn't make and object special in Java?

The above page also says that a POJO should not have to extend prespecified classes, implement prespecified Interfaces or contain prespecified Annotations. Does that also mean that POJOs are not allowed to implement interfaces like Serializable, Comparable or classes like Applets or any other user-written Class/Interfaces?

Also, does the above policy (no extending, no implementing) means that we are not allowed to use any external libraries?

Where exactly are POJOs used?

EDIT: To be more specific, am I allowed to extend/implement classes/interfaces that are part of the Java or any external libraries?

What does the term Plain Old Java Object (POJO) mean?

POJO was coined by Martin Fowler, Rebecca Parsons and Josh Mackenzie when they were preparing for a talk at a conference in September 2000. Martin Fowler in Patterns of Enterprise Application Architecture explains how to implement a Domain Model pattern in Java. After enumerating some of disadvantages of using EJB Entity Beans:

There's always a lot of heat generated when people talk about developing a Domain Model in J2EE. Many of the teaching materials and introductory J2EE books suggest that you use entity beans to develop a domain model, but there are some serious problems with this approach, at least with the current (2.0) specification.

Entity beans are most useful when you use Container Managed Persistence (CMP)...

Entity beans can't be re-entrant. That is, if you call out from one entity bean into another object, that other object (or any object it calls) can't call back into the first entity bean...

...If you have remote objects with fine-grained interfaces you get terrible performance...

To run with entity beans you need a container and a database connected. This will increase build times and also increase the time to do test runs since the tests have to execute against a database. Entity beans are also tricky to debug.

As an alternative, he proposed to use Regular Java Objects for Domain Model implementation:

The alternative is to use normal Java objects, although this often causes a surprised reaction—it's amazing how many people think that you can't run regular Java objects in an EJB container. I've come to the conclusion that people forget about regular Java objects because they haven't got a fancy name. That's why, while preparing for a talk in 2000, Rebecca Parsons, Josh Mackenzie, and I gave them one: POJOs (plain old Java objects). A POJO domain model is easy to put together, is quick to build, can run and test outside an EJB container, and is independent of EJB (maybe that's why EJB vendors don't encourage you to use them).

The main web application of my company is crying out for a nifty set of libraries to make it in some way maintainable and scalable, and one of my colleagues has suggested CSLA. So I've bought the book but as :

programmers don't read books anymore

I wanted to gauge the SOFlow community's opinion of it.

So here are my questions:

  1. How may people are using CSLA?
  2. What are the pros and cons?
  3. Does CSLA really not fit in with TDD?
  4. What are my alternatives?
  5. If you have stopped using it or decided against why?

Before I specifically answer your question, I'd like to put a few thoughts down. Is CSLA right for your project? It depends. I would personally consider CSLA for desktop based applications that does not value unit testing as a high priority. CSLA is great if you want to easily scale to an n-tier application. CSLA tends to get some flack because it does not allow pure unit testing. This is true, however like anything in technology, I believe that there is No One True Way. Unit testing may not be something you are undertaking for a specific project. What works for one team and one project may not work for another team or other project.

There are also many misconceptions in regards to CSLA. It is not an ORM. it is not a competitor to NHibernate (in fact using CLSA Business Objects & NHibernate as data access fit really well together). It formalises the concept of a Mobile Object.

1. How many people are using CSLA?
Based on the CSLA Forums, I would say there are quite a number of CSLA based projects out there. Honestly though, I have no idea how many people are actually using it. I have used it in the past on two projects.

2. What are the pros and cons?
While it is difficult to summarise in a short list, here is some of the pro/con's that come to mind.

  • It's easy to get new developers up to speed. The CSLA book and sample app are great resources to get up to speed.
  • The Validation framework is truly world class - and has been "borrowed" for many many other non-CSLA projects and technologies.
  • n-Level Undo within your business objects
  • Config line change for n-Tier scalability (Note: not even a recompile is necessary)
  • Key technologies are abstracted from the "real" code. When WCF was introduced, it had minimal impact on CSLA code.
  • It is possible to share your business objects between windows and web projects.
  • CSLA promotes the normalization of behaviour rather than the normalization of data (leaving the database for data normalization).


  • Difficulty in unit testing
  • Lack of Separation of Concern (generally your business objects have data access code inside them).
  • As CSLA promotes the normalization of behavior, rather than the normalization of data, and this can result in business objects that are named similarly, but have different purposes. This can cause some confusion and a feeling like you are not reusing objects appropriately. That said, once the physiological leap is taken, it more than makes sense - it seems inappropriate to structure objects the "old" way.
  • It's not "in fashion" to build applications this way. You may struggle to get developers who are passionate about the technology.

3. After reading this does CSLA really not fit in with TDD?
I haven't found an effective way to do TDD with CSLA. That said, I am sure there are many smarter people out there than me that may have tried this with greater success.

4. What are my alternatives?
Domain-Driven-Design is getting big push at the moment (and rightfully so - it's fantastic for some applications). There are also a number of interesting patterns developing from the introduction of LINQ (and LINQ to SQL, Entity Framework, etc). Fowlers book PoEAA, details many patterns that may be suitable for your application. Note that some patterns are competing (i.e. Active Record and Repository), and thus are meant to be used for specific scenarios. While CSLA doesn't exactly match any of the patterns described in that book, it most closely resembles Active Record (although I feel it is short-sighted to claim an exact match for this pattern).

5. If you have stopped using it or decided against why?
I didn't fully recommend CSLA for my last project, because I believe the scope of the application is too large for the benefits CSLA provides.
I would not use CSLA on a web project. I feel there are other technologies better suited to building applications in that environment.

In summary, while CSLA is anything but a silver bullet, it is appropriate for some scenarios.

Hope this helps!

I need some help from more experienced programmers. I want to improve my MVC skills. But I could not find a good tutorial on Google for MVC. Google always gives "MVC for beginners".

I understand what MVC is and I can make it, but I'm not experienced enough to do something practical in OOP.

If anyone knows a good object-oriented tutorial for MVC, please direct me to the right place — I'm looking for good links, books etc.

Links, that contain PHP-only materials, are marked with php for easier identification.

You cannot even begin to delve into MVC before you have comprehensive understanding of OOP. That include OOP practices (dependency injection, unit testing, refactoring) principles (SOLID, SoC, CQS, LoD) and common patterns (and no, singleton is not an object-oriented pattern).

MVC is an advanced architectural design pattern, which requires solid understanding. It is not meant for beginners or for tiny "hello world" applications. One uses MVC to add additional constraints to the codebase, when simple adherence to OOP practices becomes too loose to control the codebase.

The best I can suggest for you would be to begin by expanding you knowledge regarding object oriented code:

The two lectures above should cover the basics. And then move on to:

When you understand all that was explain in this series, you can expand on:

Also, I would strongly recommend for you to read (in this order):

P.S.: you might also take a look at this book (cautiously, because it has issues): Guide to PHP Design Patterns php

(Note: My question has very similar concerns as the person who asked this question three months ago, but it was never answered.)

I recently started working with MVC3 + Entity Framework and I keep reading that the best practice is to use the repository pattern to centralize access to the DAL. This is also accompanied with explanations that you want to keep the DAL separate from the domain and especially the view layer. But in the examples I've seen the repository is (or appears to be) simply returning DAL entities, i.e. in my case the repository would return EF entities.

So my question is, what good is the repository if it only returns DAL entities? Doesn't this add a layer of complexity that doesn't eliminate the problem of passing DAL entities around between layers? If the repository pattern creates a "single point of entry into the DAL", how is that different from the context object? If the repository provides a mechanism to retrieve and persist DAL objects, how is that different from the context object?

Also, I read in at least one place that the Unit of Work pattern centralizes repository access in order to manage the data context object(s), but I don't grok why this is important either.

I'm 98.8% sure I'm missing something here, but from my readings I didn't see it. Of course I may just not be reading the right sources... :\

I think the term "repository" is commonly thought of in the way the "repository pattern" is described by the book Patterns of Enterprise Application Architecture by Martin Fowler.

A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction. Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes.

On the surface, Entity Framework accomplishes all of this, and can be used as a simple form of a repository. However, there can be more to a repository than simply a data layer abstraction.

According to the book Domain Driven Design by Eric Evans, a repository has these advantages:

  • They present clients with a simple model for obtaining persistence objects and managing their life cycle
  • They decouple application and domain design from persistence technology, multiple database strategies, or even multiple data sources
  • They communicate design decisions about object access
  • They allow easy substitution of a dummy implementation, for unit testing (typically using an in-memory collection).

The first point roughly equates to the paragraph above, and it's easy to see that Entity Framework itself easily accomplishes it.

Some would argue that EF accomplishes the second point as well. But commonly EF is used simply to turn each database table into an EF entity, and pass it through to UI. It may be abstracting the mechanism of data access, but it's hardly abstracting away the relational data structure behind the scenes.

In simpler applications that mostly data oriented, this might not seem to be an important point. But as the applications' domain rules / business logic become more complex, you may want to be more object oriented. It's not uncommon that the relational structure of the data contains idiosyncrasies that aren't important to the business domain, but are side-effects of the data storage. In such cases, it's not enough to abstract the persistence mechanism but also the nature of the data structure itself. EF alone generally won't help you do that, but a repository layer will.

As for the third advantage, EF will do nothing (from a DDD perspective) to help. Typically DDD uses the repository not just to abstract the mechanism of data persistence, but also to provide constraints around how certain data can be accessed:

We also need no query access for persistent objects that are more convenient to find by traversal. For example, the address of a person could be requested from the Person object. And most important, any object internal to an AGGREGATE is prohibited from access except by traversal from the root.

In other words, you would not have an 'AddressRepository' just because you have an Address table in your database. If your design chooses to manage how the Address objects are accessed in this way, the PersonRepository is where you would define and enforce the design choice.

Also, a DDD repository would typically be where certain business concepts relating to sets of domain data are encapsulated. An OrderRepository may have a method called OutstandingOrdersForAccount which returns a specific subset of Orders. Or a Customer repository may contain a PreferredCustomerByPostalCode method.

Entity Framework's DataContext classes don't lend themselves well to such functionality without the added repository abstraction layer. They do work well for what DDD calls Specifications, which can be simple boolean expressions sent in to a simple method that will evaluate the data against the expression and return a match.

As for the fourth advantage, while I'm sure there are certain strategies that might let one substitute for the datacontext, wrapping it in a repository makes it dead simple.

Regarding 'Unit of Work', here's what the DDD book has to say:

Leave transaction control to the client. Although the REPOSITORY will insert into and delete from the database, it will ordinarily not commit anything. It is tempting to commit after saving, for example, but the client presumably has the context to correctly initiate and commit units of work. Transaction management will be simpler if the REPOSITORY keeps its hands off.

We implement an One-to-Many relationship by adding one Table's PK, as FK to the other Table. We implement a Many-to-Many relationship by adding 2 Table's PKs to a third Table.

How do we implement an IS-A Relationship ?

The Entities are TECHNICIAN and ADMINISTRATIVE which both are EMPLOYEE. I could just use an extra field in the Table EMPLOYEE(id, name, surname, role, ...AdminFields..., ...TechFields...)

but i would like to explore the IS-A option.

EDIT: I did as Donnie suggested, but without the role field.

If you have an OO application that you need to connect to a relational back-end database, I'd recommend getting Martin Fowler's Patterns of Enterprise Application Architecture.

He also has some relevant notes and diagrams on his website. Specifically, the patterns Single Table Inheritance, Class Table Inheritance and Concrete Table Inheritance describe three tactics for mapping IS-A in data tables.

If you're using Hibernate or JPA, they support mappings for all of these, though they have different names for them.

In this specific instance, I wouldn't use IS-A at all though.

Things like employee roles are better modeled as HAS-A, as

  1. You might want a single person to have multiple roles.
  2. Changing a person's role will be easier.

I'am unclear as to what the roles and responsibility of the factory class is. I know enough that the factory class should be resposible for the creation of domain objects (aggregate root) along with its associated entities and value objects.

But what is not clear to me is where the factory "layer" lies with a DDD architecture? Should the factory be calling directly into the repository to get its data or the service library?

Where does the factory fit into the following framework:
UI > App > Domain > Service > Data

Also, because the factory is the only place allowed for object creation would'nt you get circular references if you wanted to create your objects in your data and service layers?

If the role of the factory class is for object creation then what benefits does the service layer have?

I've asked a lot of questions and appreciate any response. What i'am lacking is a sample application which demonstrates how all the layers in a domain driven design project come together...Is there anything out there?

But what is not clear to me is where the factory "layer" lies with a DDD architecture? Should the factory be calling directly into the repository to get its data or the service library?

The factory should be the one-stop shop to construct domain objects. Any other part of the code that needs to do this should use the factory.

Typically, there are at least three sources of data that are used as input into a factory for domain object construction: input from the UI, the results of queries from persistence, and domain-meaningful requests. So to answer your specific question, the repository would use the factory.

Here is an example. I am using Holub's Builder pattern here. Edit: disregard the use of this pattern. I've started realizing that it doesn't mix too well with DDD factories.

// domain layer
class Order
    private Integer ID;
    private Customer owner;
    private List<Product> ordered;

    // can't be null, needs complicated rules to initialize
    private Product featured; 

    // can't be null, needs complicated rules to initialize, not part of Order aggregate
    private Itinerary schedule; 

    void importFrom(Importer importer) { ... }

    void exportTo(Exporter exporter) { ... }

    ... insert business logic methods here ...

    interface Importer
        Integer importID();
        Customer importOwner();
        Product importOrdered();

    interface Exporter
        void exportID(Integer id);
        void exportOwner(Customer owner);
        void exportOrdered(Product ordered);

// domain layer
interface OrderEntryScreenExport { ... }

// UI
class UIScreen
    public UIScreen(OrderEntryDTO dto) { ... }

// App Layer
class OrderEntryDTO implements OrderEntryScreenExport { ... }

Here is what the OrderFactory might look like:

interface OrderFactory
    Order createWith(Customer owner, Product ordered);
    Order createFrom(OrderEntryScreenExport to);
    Order createFrom(List<String> resultSets);

The logic for the featured Product and the generation of the Itinerary go in the OrderFactory.

Now here is how the factory might be used in each instance.

In OrderRepository:

public List<Order> findAllMatching(Criteria someCriteria)
    ResultSet rcds = this.db.execFindOrdersQueryWith(someCriteria.toString());
    List<List<String>> results = convertToStringList(rcds);

    List<Order> returnList = new ArrayList<Order>();

    for(List<String> row : results)

    return returnList;

In your application layer:

public void submitOrder(OrderEntryDTO dto)
    Order toBeSubmitted = this.orderFactory.createFrom(dto);


    // do other stuff, raise events, etc

Within your domain layer, a unit test perhaps:

Customer carl = customerRepo.findByName("Carl");
List<Product> weapons = productRepo.findAllByName("Ruger P-95 9mm");
Order weaponsForCarl = orderFactory.createWith(carl, weapons);;


Where does the factory fit into the following framework: UI > App > Domain > Service > Data


Also, because the factory is the only place allowed for object creation would'nt you get circular references if you wanted to create your objects in your data and service layers?

In my example, all dependencies flow from top to bottom. I used the Dependency Inversion Principle (PDF link) to avoid the problem you speak of.

If the role of the factory class is for object creation then what benefits does the service layer have?

When you have logic that doesn't fit into any single domain object OR you have an algorithm that involves orchestrating multiple domain objects, use a service. The service would encapsulate any logic that doesn't fit in anything else and delegate to domain objects where it does fit.

In the example I scribbled here, I imagine that coming up with an Itinerary for the Order would involve multiple domain objects. The OrderFactory could delegate to such a service.

BTW, the hierarchy you described should probably be UI > App > Domain Services > Domain > Infrastructure (Data)

I've asked a lot of questions and appreciate any response. What i'am lacking is a sample application which demonstrates how all the layers in a domain driven design project come together...Is there anything out there?

Applying Domain Driven Design and Patterns by Jimmy Nilsson is a great compliment to Eric Evans' Domain-Driven Design. It has lots of code examples, though I don't know if there is an emphasis on layering. Layering can be tricky and is almost a topic separate from DDD.

In the Evans book, there is a very small example of layering you might want to check out. Layering is an enterprise pattern, and Martin Fowler wrote Patterns of Enterprise Application Architecture, which you might find useful too.

I wrote a class that tests for equality, less than, and greater than with two doubles in Java. My general case is comparing price that can have an accuracy of a half cent. 59.005 compared to 59.395. Is the epsilon I chose adequate for those cases?

private final static double EPSILON = 0.00001;

 * Returns true if two doubles are considered equal.  Tests if the absolute
 * difference between two doubles has a difference less then .00001.   This
 * should be fine when comparing prices, because prices have a precision of
 * .001.
 * @param a double to compare.
 * @param b double to compare.
 * @return true true if two doubles are considered equal.
public static boolean equals(double a, double b){
    return a == b ? true : Math.abs(a - b) < EPSILON;

 * Returns true if two doubles are considered equal. Tests if the absolute
 * difference between the two doubles has a difference less then a given
 * double (epsilon). Determining the given epsilon is highly dependant on the
 * precision of the doubles that are being compared.
 * @param a double to compare.
 * @param b double to compare
 * @param epsilon double which is compared to the absolute difference of two
 * doubles to determine if they are equal.
 * @return true if a is considered equal to b.
public static boolean equals(double a, double b, double epsilon){
    return a == b ? true : Math.abs(a - b) < epsilon;

 * Returns true if the first double is considered greater than the second
 * double.  Test if the difference of first minus second is greater then
 * .00001.  This should be fine when comparing prices, because prices have a
 * precision of .001.
 * @param a first double
 * @param b second double
 * @return true if the first double is considered greater than the second
 *              double
public static boolean greaterThan(double a, double b){
    return greaterThan(a, b, EPSILON);

 * Returns true if the first double is considered greater than the second
 * double.  Test if the difference of first minus second is greater then
 * a given double (epsilon).  Determining the given epsilon is highly
 * dependant on the precision of the doubles that are being compared.
 * @param a first double
 * @param b second double
 * @return true if the first double is considered greater than the second
 *              double
public static boolean greaterThan(double a, double b, double epsilon){
    return a - b > epsilon;

 * Returns true if the first double is considered less than the second
 * double.  Test if the difference of second minus first is greater then
 * .00001.  This should be fine when comparing prices, because prices have a
 * precision of .001.
 * @param a first double
 * @param b second double
 * @return true if the first double is considered less than the second
 *              double
public static boolean lessThan(double a, double b){
    return lessThan(a, b, EPSILON);

 * Returns true if the first double is considered less than the second
 * double.  Test if the difference of second minus first is greater then
 * a given double (epsilon).  Determining the given epsilon is highly
 * dependant on the precision of the doubles that are being compared.
 * @param a first double
 * @param b second double
 * @return true if the first double is considered less than the second
 *              double
public static boolean lessThan(double a, double b, double epsilon){
    return b - a > epsilon;

If you are dealing with money I suggest checking the Money design pattern (originally from Martin Fowler's book on enterprise architectural design).

I suggest reading this link for the motivation:

There's a lot of sites out there that teach people how to build better software--but why is it that there are very few sites that actually give detailed descriptions of the domains that we (as programmers) are supposed to create? One can only construct so many inventory, accounting, and ERP systems before a pattern of common requirements start to emerge among the different types of systems. Logically speaking, if programmers spend so much time trying to create reusable components in their architectures, does that imply that they should have to have some reusable "blueprint" that describes the systems that they're supposed to create? In other words, it seems like the focus of software development has been too focused on "how" software should be built rather than to catalog and accurately specify (with detailed requirements) "what" should be used in the first place.

So my question is this: Has there been any work done to catalog all the different types of system specifications into a single place, all on a single site? If lacking the proper requirements at the start of the project is one of the banes of software development, wouldn't it make more sense to be able to 'reuse' requirement specifications from previous systems of the same type that have already been written?

Check out the Data Model Resource Book by Len Silverston:

It approaches reusable design from the data model point of view, as opposed to end user requirements or OO designs. However, I find that to be very useful - once you have a good grasp of the data model, you have a big jump on the requirements and the entities that will eventually be modeled as classes.

You might want to check out Martin Fowler's Patterns of Enterprise Application Architecture - while not specs, it seems to be about the sort of things you are after.

Disclaimer: I haven't read it myself, I only know of its existence.

What's the penetration of design patterns in the real world? Do you use them in your day to day job - discussing how and where to apply them with your coworkers - or do they remain more of an academic concept?

Do they actually provide actual value to your job? Or are they just something that people talk about to sound smart?

Note: For the purpose of this question ignore 'simple' design patterns like Singleton. I'm talking about designing your code so you can take advantage of Model View Controller, etc.

I absolutely use design patterns. At this point I take MVC for granted as a design pattern. My primary reason for using them is that I am humble enough to know that I am likely not the first person to encounter a particular problem. I rarely start a piece of code knowing which pattern I am going to use; I constantly watch the code to see if it naturally develops into an existing pattern.

I am also very fond of Martin Fowler's Patterns of Enterprise Application Architecture. When a problem or task presents itself, I flip to related section (it's mostly a reference book) and read a few overviews of the patterns. Once I have a better idea of the general problem and the existing solutions, I begin to see the long term path my code will likely take via the experience of others. I end up making much better decisions.

Design patterns definitely play a big role in all of my "for the future" ideas.

I've heard that projects developed using TDD are easier to refactor because the practice yields a comprehensive set of unit tests, which will (hopefully) fail if any change has broken the code. All of the examples I've seen of this, however, deal with refactoring implementation - changing an algorithm with a more efficient one, for example.

I find that refactoring architecture is a lot more common in the early stages where the design is still being worked out. Interfaces change, new classes are added & deleted, even the behavior of a function could change slightly (I thought I needed it to do this, but it actually needs to do that), etc... But if each test case is tightly coupled to these unstable classes, wouldn't you have to be constantly rewriting your test cases each time you change a design?

Under what situations in TDD is it okay to alter and delete test cases? How can you be sure that altering the test cases don't break them? Plus it seems that having to synchronize a comprehensive test suite with constantly changing code would be a pain. I understand that the unit test suite could help tremendously during maintenance, once the software is built, stable, and functioning, but that's late in the game wheras TDD is supposed to help early on as well.

Lastly, would a good book on TDD and/or refactoring address these sort of issues? If so, which would you recommend?

I would recommended (as others have):

I'm trying to understand the concepts behind DDD, but I find it hard to understand just by reading books as they tend to discuss the topic in a rather abstract way. I would like to see some good implementations of DDD in code, preferably in C#.

Are there any good examples of projects practicing DDD in the open source world?

A good read is Jimmi Nilssons book (and blog for that matter) Applying domain driven design

It's a mixture of Evans and Fowlers books (Domain-Driven Design - Evans), and (Patterns of Enterprise Application Architecture - Fowler)

Code Camp Server, Jeffrey Palermo's sample code for the book ASP.NET MVC in Action is open source and uses DDD.

(Same as my answer in Good Domain Driven Design samples)

I am mainly looking for good development practices specially when working in conjunction with mysql. I searched through the questions but could not find any related questions. I would appreciate if some one share their practices and wisdom gained through experience.

Apart from some coding standards, I am also looking for design standards and common architectural practices.

Background: I started my career with Java, and over the years I moved to C#/.NET space. I have been practicing architect for over 3 years now. Just added this to give some idea to people.

I would suggest that you familiarize yourself with the history of PHP, I know that doing so has given me a much greater appreciation of what PHP is today and where it has come from.

In short, PHP was written by Rasmus Lerdorf to provide simple wrapper functions for the C code that was actually doing the heavy-lifting so that he could have a simpler language / syntax for writing templates that needed to behave dynamically. The growth of PHP and the community which surrounds it is best described as organic. And much like other things that grow organically, its more than a little messy, asymmetrical, and downright non-congruent.

Once you understand PHP and its community, you need to embrace PHP for everything that it is and everything that it is not. This idea was best presented by Terry Chay in his article PHP without PHP. He's specifically talking about the concept of funky caching, but he captures the concept of coding for PHP as if it were PHP and not (insert favorite language here) better than anyone I've ever seen. In other words, don't try to make PHP into Java, C#, Ruby, etc because if you do you'll fail and you'll hate your life.

Take a look at How is PHP Done the Right Way?.

I must say that you must first, last, and always avoid the tendency of most beginning PHP developers to use the spaghetti-code anti-pattern. In other words, if you find that you're writing code that contains sql queries, manipulation of data, validation of data, and html output all in a single php script, then you're doing it wrong.

In order to avoid this, it will be helpful to learn something about the nature of web-oriented design patterns. This of course precludes a familiarity with object-oriented programming. But once you've learned the basics of object-oriented programming in PHP, study the MVC design pattern. You don't have to implement this exactly but using the basic ideas of Model-View-Controller will allow you to avoid the blob script problem that most newbies tend to create.

On this point, I would strongly recommend that you take any code snippets you find on the web with a grain of salt. And even if you find it in a book you'll have to consider how old the book is. PHP as a language has advanced quite a long ways and you can't just take code samples at face value because, depending on their age, they may be using workarounds that were valid in 3.x or 4.x but simply are no longer necessary with newer features.

One great thing to do is to study the various frameworks out there. Evaluate what you like and what you don't. Maybe even work up each of the quickstarts that are provided with the framework documentation so that you can start to get an idea of what you like and don't like. And I would strongly recommend that you review the code from the frameworks as well as several other open-source projects so that you can get a feel for how others do things in PHP. Again, take it all with a grain of salt because every PHP developer has their own pet peeves and nuances and none of us is right all the time. In fact, most of the time with PHP there are going to be several pretty good ways to do something.

If you want to get a better understanding of the patterns that are being implemented by the frameworks and are commonly thrown around in the common vernacular on SO, I would suggest that you read Fowler and GoF. They'll teach all about the basic design patterns you'll use in your development efforts.

Specifically watch for the following:

  • Function files that contain LOTS of functions. This is most likely representative of a need to either put functions directly in the scripts that need them or it may also indicate an opportunity to create some more generic functions that can be made to fulfill the roles of a couple of highly specific functions. Of course, if you're building cohesive, well-encapsulated classes you shouldn't run into this problem.
  • The do everything class. This is a blob anti-pattern and is really nasty. In this case you need to identify where cohesion and encapsulation are breaking down and use those points as opportunities to break up the class into several smaller, more maintainable classes.
  • SQL queries that don't use parameterized queries or at least escaped parameters. Very, very, very bad.
  • Any instance where validation is not being performed or is only performed client-side. When developing for the web, the only way to keep your site and your users safe is to assume that everyone else is a black hat.
  • A sudden obsessive desire to use a template engine. PHP is a templating language. Make certain that you have clear reasons for adding another layer onto your website before using a template engine.

For further reading please look at the following:

PHP Application Design Patterns
Defend PHP -- useful to give you an idea of the most common criticisms.
Security of strip_tags and mysqlirealescapestring
What should Every PHP Programmer Know
How to Structure an ORM
Best Way to Organize Class Hierarchy
Main Components / Layers of PHP App
Why use Framework for PHP
Recommended Security Training for PHP

I've almost finished my Data Mapper, but now I'm at the point where it comes to relationships.

I will try to illustrate my ideas here. I wasn't able to find good articles / informations on this topic, so maybe I'm re-inventing the wheel (for sure I am, I could just use a big framework - but I want to learn by doing it).

1:1 Relationships

First, lets look at 1:1 relationships. In general, when we've got an domain class called "Company" and one called "Address", our Company class will have something like address_id. Lets say in most cases we just display a list of Companies, and the address is only needed when someone looks at the details. In that case, my Data Mapper (CompanyDataMapper) simply loads lazily, meaning it will just fetch that address_id from the database, but will not do a join to get the address data as well.

In general, I have an getter method for every Relationship. So in this case, there's an getAddress(Company companyObject) method. It takes an company object, looks for it's address property and - if it's NULL - fetches the corresponding Address object from the database, using the Mapper class for that Address object (AddressDataMapper), and assigns that address object to the address property of the specified company object.

Important: Is a Data Mapper allowed to use another Data Mapper?

Lets say in most cases you need both the company object AND the address object, because you always display it in a list all together. In this case, the CompanyDataMapper not only fetches company objects, but does an SQL query with JOIN to also get all the fields of the address object. Finally, it iterates over the record set and feeds new objects with their corresponding values, assigning the address object to the company object.

Sounds simple, so far.

1:n Relationships

How about these? The only difference to 1:1 is, that an Company may have multiple Address objects. Lets have a look: When we're most of the time only interested in the Company, the Data Mapper would just set the addresses property of the company object to NULL. The addresses property is an array which may reference none, one or multiple addresses. But we don't know yet, since we load lazily, so it's just NULL. But what, if we would need all the addresses in most cases as well? If we would display a big list with all companys together with all their addresses? In this case, things start to get really ugly. First, we can't join the address table fifty times for every address object (I strongly believe that's impossible, and if it is, performance would be below zero). So, when we think this further down the road, it's impossible to NOT load lazily in this case.

Important: Is this true? Must I send out 100 queries to get 100 address objects, if I have 10 companies with each 10 addresses?

m:n Relationships

Lets say an address object only contains the country, state, city, road and house number. But one house could be a big business tower with lots of companies in them. Like one of those modern office buildings where anyone can rent a small rom to show off that tower on its website. So: Many companies can share the same address.

I have no plans yet to deal with that kind of problem.

Important: Probably it's not a bigger problem than the 1:n Relationships?

If anyone knows a good ressource that goes into details about solving / implementing this, I would be happy about a link!

I am looking forward to any answers you'll get on this topic, but in the meantime why not just hop over to Amazon (or your local books dealer) and finally buy

These book contain the original patterns you have been pointed at in various of your questions and are considered reference works in Design Patterns and Software Architecture.

Is there a Java Application Architecture Guide that is a counterpart of this: ?

The following should be helpful to you

  1. Core J2EE Patterns
  2. Effective Enterprise Java
  3. Patterns of Enterprise Application Architecture
  4. Head First Design Patterns
  5. J2EE Blueprints
  6. Sun Certified Enterprise Architect, Study Guide

Although, having had a quick glance at the document from codeplex, I can tell you that probably 70-80% of what is in there, applies to Java as well.

I've been confused by what I've been reading during my research on the repository pattern. I'm wondering if folks are (incorrectly?) using that word when they simply mean a data access layer.

Since "repository" is not found in the index of Design Patterns (GoF), I've turned to Patterns of Enterprise Application Architecture (Fowler). Fowler seems pretty clear (page 323) when he states that clients create a criteria object and pass it to the repository to get the results. It looks something like this:

public class Person
    public List<Person> Dependents()
        Repository repository = Registry.personRepository();
        Criteria criteria = new Criteria();
        criteria.equal(Person.BENEFACTOR, this);
        return repository.matching(criteria);

Is the criteria object what makes the repository a repository? If not, what does? If abstracting the persistence mechanism (and therefore constructing queries) is the goal, in what way does the repository differ from a simpe DAL/ORM call like this:

public class PersonLogic
    public List<Person> GetDependents()
        IPersonData personData = DependencyContainer.Resolve<IPersonData>();
        return personData.GetDependents();

To me, the difference looks like this:
* With the repository pattern, the client constructs different criteria objects and calls the Matching() method on it.
* With the simple DAL, clients just call different methods based on what they want.

Is there more to it than this? Are programmers mistakenly using the term "repository" when they really mean DAL?


David Osborne sent this link to Persistence Patterns. It states:

Basically, the Repository pattern just means putting a façade over your persistence system so that you can shield the rest of your application code from having to know how persistence works.

That's really what a data access layer is. It really appears to me that a repository and a DAL are the same thing, and maybe a "true" repository uses the criteria object.

Take a look at the "Using the IQueryable interface" section and beyond at Extending and Enhancing the Orders and Registrations Bounded Context. It provides an insightful and balanced discussion of DAO/Repository implementations.

As subsequently highlighted by Bob Horn, the Persistence Patterns articles summarises that:

Basically, the Repository pattern just means putting a façade over your persistence system so that you can shield the rest of your application code from having to know how persistence works.

Up until now I've been using Active records in all my c# database driven applications. But now my application requires my persistence code being split from my business objects. I have read a lot of posts regarding Martin Fowler's data mapping pattern, but my knowledge of this pattern is still very limited.

Let's use the following example:

If I have 2 tables - Customer and CustomerParameters. The CustomerParameters table contains default Customer values for creating a new Customer.

I will then have to create a CustomersMapper class to handle all of the Customer persistence. My Customer and CustomersList class will then collaborate with this mapper class in order to persist customer data.

I have the following questions:

  1. How would I transfer raw data TO & FROM my Customer class to the mapper without breaking certain business rules? DTO's?

  2. Is it acceptable to have a SaveAll and LoadAll method in my Mapper class for updating and loading multiple customers' data? If so, in case of SaveAll, how will the mapper know when to update or insert data?

  3. Will the Customer mapper class be responsible for retrieving the default values from the CustomerParameters table as well, or will it be better to create a CustomerParameters mapper?

A O/R mapper tool is not really here. The database I'm using is Transactional and requires that I write my own Mapper Pattern.

Any ideas and comments will be greatly appreciated.

Shaun I would answer your questions this way:

ad 1) Mapper is responsible for creating Customer object. Your Mapper object will have something like RetrieveById method (for example). It will accept an ID and somehow (that't he responsibility of the Mapper object) construct the valid Customer object. The same is true the other way. When you call Mapper.Update method with a valid Customer object, the Mapper object is responsible for making sure that all the relevant data are persisted (wherever appropriate - db, memory, file, etc.)

ad 2) As I noted above retrieve/persist are methods on Mapper object. It is its responsibility to provide such a functionality. Therefore LoadAll, SaveAll (probably passing an array of value objects) are valid Mapper methods.

ad 3) I would say yes. But you can separate various aspects of Mapper objects into separate classes (if you want to/need to): default values, rule validation, etc.

I hope it helps. I really suggest/recommend you to read Martin Fowler's book Patterns of Enterprise Application Architecture.

Consider a Database interaction module written in PHP that contains classes for interacting with the database. I have not started coding the class so I won't be able to give code snippets.

There will be one class per database table as explained below.

User - A class for interacting with the user table. The class contains functions such as createUser, updateUser, etc.

Locations - A class for interacting with the locations table. The class contains functions such as searchLocation, createLocation, updateLocation, etc.

In addition, I am thinking of creating another class as follows: -

DatabaseHelper : A class that will have a member that represents the connection to the database. This class will contain the lower level methods for executing SQL queries such as executeQuery(query,parameters), executeUpdate(query,parameters) and so on.

At this point, I have two options to use the DatabaseHelper class in other classes : -

  1. The User and Locations class will extend the DatabaseHelper class so that they can use the inherited executeQuery and executeUpdate methods in DatabaseHelper. In this case, DatabaseHelper will ensure that there is only one instance of the connection to the database at any given time.
  2. The DatabaseHelper class will be injected in the User and Locations class through a Container class that will make User and Location instances. In this case, the Container will make sure that there is only one instance of DatabaseHelper in the application at any given time.

These are the two approaches that quickly come to my mind. I want to know which approach to go with. It is possible that both these approaches are not good enough, in which case, I want to know any other approach that I can go with to implement the database interaction module.


Note that the Container class will contain a static member of type DatabaseHelper. It will contain a private static getDatabaseHelper() function that will return an existing DatabaseHelper instance or create a new DatabaseHelper instance if one does not exists in which case, it will populate the connection object in DatabaseHelper. The Container will also contain static methods called makeUser and makeLocation that will inject the DatabaseHelper into User and Locations respectively.

After reading a few answers, I realize that the initial question has almost been answered. But there is still a doubt that needs to be clarified before I can accept the final answer which is as follows.

What to do when I have multiple databases to connect to rather than a single database. How does the DatabaseHelper class incorporate this and how does the container inject appropriate database dependencies in the User and Location objects?

Lets answer your questions from top to bottom, and see what I can add to what you say.

There will be one class per database table as explained below.

User - A class for interacting with the user table. The class contains functions such as createUser, updateUser, etc.

Locations - A class for interacting with the locations table. The class contains functions >such as searchLocation, createLocation, updateLocation, etc.

Essentially you have to choices here. The method you described is called the active record pattern. The object itself knows how and where it is stored. For simple objects that interact with a database to create / read / update / delete, this pattern is really usefull.

If the database operations become more extensive and less simple to understand, it is often a good choice to go with a data mapper (eg. this implementation). This is a second object that handles all the database interactions, while the object itself (eg. User or Location) only handles operations that are specific to that object (eg. login or goToLocation). If you ever want to chance the storage of your objects, you will only have to create a new data mapper. Your object won't even know that something changed in the implementation. This enforces encapsulation and seperation of concerns.

There are other options, but these two are the most used ways to implement database interactions.

In addition, I am thinking of creating another class as follows: -

DatabaseHelper : A class that will have a static member that represents the connection to the database. This class will contain the lower level methods for executing SQL queries such as executeQuery(query,parameters), executeUpdate(query,parameters) and so on.

What you are describing here sounds like a singleton. Normally this isn't really a good design choice. Are you really, really certain that there will never be a second database? Probably not, so you should not confine yourself to an implementation that only allowes for one database connection. Instead of making a DatabaseHelper with static members, you can better create a Database object with some methods that allow you to connect, disconnect, execute a query, etc. This way you can reuse it if you ever need a second connection.

At this point, I have two options to use the DatabaseHelper class in other classes : -

  1. The User and Locations class will extend the DatabaseHelper class so that they can use the inherited executeQuery and executeUpdate methods in DatabaseHelper. In this case, DatabaseHelper will ensure that there is only one instance of the connection to the database at any given time.
  2. The DatabaseHelper class will be injected in the User and Locations class through a Container class that will make User and Location instances. In this case, the Container will make sure that there is only one instance of DatabaseHelper in the application at any given time.

These are the two approaches that quickly come to my mind. I want to know which approach to go with. It is possible that both these approaches are not good enough, in which case, I want to know any other approach that I can go with to implement the database interaction module.

The first option isn't really viable. If you read the description of inheritance, you will see that inheritance is normally used to create a subtype of an existing object. An User is not a subtype of a DatabaseHelper, nor is a location. A MysqlDatabase would be a subtype of a Database, or a Admin would be a subtype of an User. I would advise against this option, as it isn't following the best practices of object oriented programming.

The second option is better. If you choose to use the active record method, you should indeed inject the Database into the User and Location objects. This should of course be done by some third object that handles all these kind of interactions. You will probably want to take a look at dependency injection and inversion of control.

Otherwise, if you choose the data mapper method, you should inject the Database into the data mapper. This way it is still possible to use several databases, while seperating all your concerns.

For more information about the active record pattern and the data mapper pattern, I would advise you to get the Patterns of Enterprise Application Architecture book of Martin Fowler. It is full of these kind of patterns and much, much more!

I hope this helps (and sorry if there are some really bad English sentences in there, I'm not a native speaker!).

== EDIT ==

Using the active record pattern of data mapper pattern also helps in testing your code (like Aurel said). If you seperate all peaces of code to do just one thing, it will be easier to check that it is really doing this one thing. By using PHPUnit (or some other testing framework) to check that your code is properly working, you can be pretty sure that no bugs will be present in each of your code units. If you mix up the concerns (like when you choose option 1 of your choices), this will be a whole lot harder. Things get pretty mixed up, and you will soon get a big bunch of spaghetti code.

== EDIT2 ==

An example of the active record pattern (that is pretty lazy, and not really active):

class Controller {
    public function main() {
        $database = new Database('host', 'username', 'password');

        $user = new User($database);
        $user->name = 'Test';


        $otherUser = new User($database, 5);

class Database {
    protected $connection = null;

    public function __construct($host, $username, $password) {
        // Connect to database and set $this->connection

    public function selectDatabase($database) {
        // Set the database on the current connection

    public function execute($query) {
        // Execute the given query

class User {
    protected $database = null;

    protected $id = 0;
    protected $name = '';

    // Add database on creation and get the user with the given id
    public function __construct($database, $id = 0) {
        $this->database = $database;

        if ($id != 0) {

    // Get the user with the given ID
    public function load($id) {
        $sql = 'SELECT * FROM users WHERE id = ' . $this->database->escape($id);
        $result = $this->database->execute($sql);

        $this->id = $result['id'];
        $this->name = $result['name'];

    // Insert this user into the database
    public function insert() {
        $sql = 'INSERT INTO users (name) VALUES ("' . $this->database->escape($this->name) . '")';

    // Update this user
    public function update() {
        $sql = 'UPDATE users SET name = "' . $this->database->escape($this->name) . '" WHERE id = ' . $this->database->escape($this->id);

    // Delete this user
    public function delete() {
        $sql = 'DELETE FROM users WHERE id = ' . $this->database->escape($this->id);

    // Other method of this user
    public function login() {}
    public function logout() {}

And an example of the data mapper pattern:

class Controller {
    public function main() {
        $database = new Database('host', 'username', 'password');

        $userMapper = new UserMapper($database);

        $user = $userMapper->get(0);
        $user->name = 'Test';

        $otherUser = UserMapper(5);

class Database {
    protected $connection = null;

    public function __construct($host, $username, $password) {
        // Connect to database and set $this->connection

    public function selectDatabase($database) {
        // Set the database on the current connection

    public function execute($query) {
        // Execute the given query

class UserMapper {
    protected $database = null;

    // Add database on creation
    public function __construct($database) {
        $this->database = $database;

    // Get the user with the given ID
    public function get($id) {
        $user = new User();

        if ($id != 0) {
            $sql = 'SELECT * FROM users WHERE id = ' . $this->database->escape($id);
            $result = $this->database->execute($sql);

            $user->id = $result['id'];
            $user->name = $result['name'];

        return $user;

    // Insert the given user
    public function insert($user) {
        $sql = 'INSERT INTO users (name) VALUES ("' . $this->database->escape($user->name) . '")';

    // Update the given user
    public function update($user) {
        $sql = 'UPDATE users SET name = "' . $this->database->escape($user->name) . '" WHERE id = ' . $this->database->escape($user->id);

    // Delete the given user
    public function delete($user) {
        $sql = 'DELETE FROM users WHERE id = ' . $this->database->escape($user->id);

class User {
    public $id = 0;
    public $name = '';

    // Other method of this user
    public function login() {}
    public function logout() {}

== EDIT 3: after edit by bot ==

Note that the Container class will contain a static member of type DatabaseHelper. It will contain a private static getDatabaseHelper() function that will return an existing DatabaseHelper instance or create a new DatabaseHelper instance if one does not exists in which case, it will populate the connection object in DatabaseHelper. The Container will also contain static methods called makeUser and makeLocation that will inject the DatabaseHelper into User and Locations respectively.

After reading a few answers, I realize that the initial question has almost been answered. But there is still a doubt that needs to be clarified before I can accept the final answer which is as follows.

What to do when I have multiple databases to connect to rather than a single database. How does the DatabaseHelper class incorporate this and how does the container inject appropriate database dependencies in the User and Location objects?

I think there is no need for any static property, nor does the Container need those makeUser of makeLocation methods. Lets assume that you have some entry point of your application, in which you create a class that will control all flow in your application. You seem to call it a container, I prefer to call it a controller. After all, it controls what happens in your application.

$controller = new Controller();

The controller will have to know what database it has to load, and if there is one single database or multiple ones. For example, one database contains the user data, anonther database contains the location data. If the active record User from above and a similar Location class are given, then the controller might look as follows:

class Controller {
    protected $databases = array();

    public function __construct() {
        $this->database['first_db'] = new Database('first_host', 'first_username', 'first_password');

        $this->database['second_db'] = new Database('second_host', 'second_username', 'second_password');

    public function showUserAndLocation() {
        $user = new User($this->databases['first_database'], 3);
        $location = $user->getLocation($this->databases['second_database']);

        echo 'User ' . $user->name . ' is at location ' . $location->name;

    public function showLocation() {
        $location = new Location($this->database['second_database'], 5);

        echo 'The location ' . $location->name . ' is ' . $location->description;

Probably it would be good to move all the echo's to a View class or something. If you have multiple controller classes, it might pay off to have a different entrypoint that creates all databases and pushes them in the controller. You could for example call this a front controller or an entry controller.

Does this answer you open questions?

Does anyone know of an already implemented money type for the .NET framework that supports i18n (currencies, formatting, etc)? I have been looking for a well implemented type and can't seem to find one.

i would use integer/long, and use a very low denomination like cents (or pence) - then there would be no decimal to work with, and all calculations can be rounded to the nearest cent.

or, take a look at Martin Fowler's book "Patterns of Enterprise Application Architecture". In that book, he talked about how to implement a money class.

Can someone explain these 3 concepts and the differences between them with respect to an MVC framework along with an example. To me these appear almost equivalent, and it seems they are used interchangeably in some articles and not in others.

The terms you are confused about are: "domain objects", "domain entities" and "model objects". While usually used interchangeably, the domain entities and model object can also be instances of active record pattern (basically: domain objects with added storage logic).

In ordinary domain object there is no storage logic. It gets handled by data mappers.

The term "model objects" comes from Fowler's books (read PoEAA for more details), and, IMHO, is part of the confusions MVC, because the entire model is an application layer (MVC consists of it and presentation layer), which contains those "model objects", which are usually dealt with by services (in that image, the model layer is all three concentric circles together).

I much prefer to use "domain object" term instead.

The term "domain entity" (or "entity object") is usually used when author implies that the object is a direct representation of a storage structure (more often - a database table). These are also almost always implementations of active record.

P.S.: in some articles you would also see term "models" (plural). It usually is not directly related to MVC design pattern, because it talks about Rails-like architecture, where "models" are just active records, that get directly exposed-to/created-by controller.

.. not sure whether this confused you more

I code for a while now and learned several programming languages. I programmed a lot of little tools and such. I think I master the act of coding itself pretty good so I have e.g. no problems with syntax, I got a pretty good understanding of what is going on under the hood (reasonable assembler knowledge) and so on.

My big problem though is: I just can't design bigger/more complex applications. I learned the principles of OOP, design patterns, learned some basic lisp programming and all stuff I could find and thought it would help me with my issue.

But no matter what I try, how long I try: I just can't get it right. My designs always seem wrong to me somehow. Cause of that I never drawn through a bigger project, i'm kinda never satisfied with the structure of my program.

Have you had a similiar problem? How did you manage to solve it? Got you any hints for me on how to go on?

Design itself is an iterative activity. You first start with a certain design and then in phases you make it better.

Design is not about achiveing perfection, which can't even be achieved in larger application. Design is all about making good balances and tradeoffs that in the end provide a good, robust and maintainable application, that conforms to the requirements.

You will never get it 100% right on all sides.

Reading a few good books on design/architecture will not make you directly a rock star on the matter but it will certainly give you the tools that you can use to improve and perfect your skills.

Here are some examples of books:

Of course practical experience also counts.

I'm basically wondering if Python has any OOP shortcomings like PHP does. PHP has been developing their OOP practices for the last few versions. It's getting better in PHP but it's still not perfect. I'm new to Python and I'm just wondering if Python's OOP support is better or just comparable.

If there are some issues in Python OOP which don't follow proper OOP practices I would definitely like to know those. PHP for instance, doesn't allow for multiple inheritance as far as I'm aware.

Thanks Everyone!

Edit: How about support for Public and Private? or support of variable types. I think these are important regarding building OOP software.

I think they're comparable at this point. As a simple test, I doubt there's any pattern in Design Patterns or Patterns of Enterprise Application Architecture, arguably the two most influential books in OOP, that is impossible to implement in either language.

Both languages have come along by leaps and bounds since their infancies.

As far as multiple inheritance, it often creates more problems than it solves, and is, these days, commonly left out of languages as an intentional design decision.

Anyone please suggest a good design and architecture book for .Net.

Is there any book I can refer to which has case studies, examples, etc. so that I can update my knowledge well in this field?

In case it's not available for .Net, please suggest in Java also.

Thanks in advance Swapna MC

Here's are a few good enterprise architecture books (based on Java, but the general concepts still apply):

A few of these patterns are a little old, but still useful to know.

If you're interested in WCF for a service-oriented architecture:

Or for framework design:

I would recommend this book: .NET: Architecting Applications for the Enterprise

Not a .net book, but the classic book here is Patterns of Enterprise Application Architecture

I enjoyed Head First Design Patterns:

More design than architecture (obviously) but it makes heavy use of examples. Examples are in Java, btw.

Architectural approaches can vary greatly depending on what you're trying to build. I.e.- Architecting a specific software's internal's, or architecting a distributed system, etc.

For a given software program's internals, I like Patterns of Enterprise Application Architecture as a good reference.

I have also used the SEDA architectural style for some high throughput event-driven applications. The SEDA homepage has the original paper and references to other projects using this style. You might have heard of the Java Open Source projects: MULE and Apache Camel.

Also check out Enterprise Integration Patterns, which is a great companion book to PoEAA. This one pretty much helps you architect the interconnection between distributed systems. Lots of tools in this area... from XMPP to AMQP, to MULE, to JMS, etc.

And I have to suggest reviewing the REST Architectural Style since it is important in today's web software. There is a lot of material about REST, but primarily read (and reread) Roy Fielding's dissertation.

I have to design a Data Access Layer with .NET that probably will use more than one database management system (Mysql and Sql Server) with the same relational design.

Basically, it has to be simple to switch from one database to another so I would like you to recommend me some web-sites or books that has been useful for you, with common design patterns or information in general to implement this kind of data access layer.

Thank you.

In general, I second John Nolan's recommendation of Patterns of Enterprise Application Architecture.

More specifically, I would always recommend that you hide your Data Access Layer behind an interface and use Dependency Injection to inject a particular Data Access Component into your Domain Logic at run-time.

You can use a Dependency Injection Container or do it manually.

On the technology side I would recommend Microsoft's Entity Framework, since your data access needs seem to be constrained to relational databases. The Entity Framework is Microsoft's official OR/M and it has providers for many different RDBMSs, as well as LINQ support.

I'm really struggling with a recurring OOP / database concept.

Please allow me to explain the issue with pseudo-PHP-code.

Say you have a "user" class, which loads its data from the users table in its constructor:

class User {
    public $name;
    public $height;

    public function __construct($user_id) {
        $result = Query the database where the `users` table has `user_id` of $user_id
        $this->name= $result['name'];
        $this->height = $result['height'];

Simple, awesome.

Now, we have a "group" class, which loads its data from the groups table joined with the groups_users table and creates user objects from the returned user_ids:

class Group {
    public $type;
    public $schedule;
    public $users;

    public function __construct($group_id) {
        $result = Query the `groups` table, joining the `groups_users` table,
                    where `group_id` = $group_id
        $this->type = $result['type'];
        $this->schedule = $result['schedule'];

        foreach ($result['user_ids'] as $user_id) {
            // Make the user objects
            $users[] = new User($user_id);

A group can have any number of users.

Beautiful, elegant, amazing... on paper. In reality, however, making a new group object...

$group = new Group(21);  // Get the 21st group, which happens to have 4 users

...performs 5 queries instead of 1. (1 for the group and 1 for each user.) And worse, if I make a community class, which has many groups in it that each have many users within them, an ungodly number of queries are ran!

The Solution, Which Doesn't Sit Right To Me

For years, the way I've got around this, is to not code in the above fashion, but instead, when making a group for instance, I would join the groups table to the groups_users table to the users table as well and create an array of user-object-like arrays within the group object (never using/touching the user class):

class Group {
    public $type;
    public $schedule;
    public $users;

    public function __construct($group_id) {
        $result = Query the `groups` table, joining the `groups_users` table,
                    **and also joining the `users` table,**
                    where `group_id` = $group_id
        $this->type = $result['type'];
        $this->schedule = $result['schedule'];

        foreach ($result['users'] as $user) {
            // Make user arrays
            $users[] = array_of_user_data_crafted_from_the_query_result;

...but then, of course, if I make a "community" class, in its constructor I'll need to join the communities table with the communities_groups table with the groups table with the groups_users table with the users table.

...and if I make a "city" class, in its constructor I'll need to join the cities table with the cities_communities table with the communities table with the communities_groups table with the groups table with the groups_users table with the users table.

What an unmitigated disaster!

Do I have to choose between beautiful OOP code with a million queries VS. 1 query and writing these joins by hand for every single superset? Is there no system that automates this?

I'm using CodeIgniter, and looking into countless other MVC's, and projects that were built in them, and cannot find a single good example of anyone using models without resorting to one of the two flawed methods I've outlined.

It appears this has never been done before.

One of my coworkers is writing a framework that does exactly this - you create a class that includes a model of your data. Other, higher models can include that single model, and it crafts and automates the table joins to create the higher model that includes object instantiations of the lower model, all in a single query. He claims he's never seen a framework or system for doing this before, either.

Please Note: I do indeed always use separate classes for logic and persistence. (VOs and DAOs - this is the entire point of MVCs). I have merely combined the two in this thought-experiment, outside of an MVC-like architecture, for simplicity's sake. Rest assured that this issue persists regardless of the separation of logic and persistence. I believe this article, introduced to me by James in the comments below this question, seems to indicate that my proposed solution (which I've been following for years) is, in fact, what developers currently do to solve this issue. This question is, however, attempting to find ways of automating that exact solution, so it doesn't always need to be coded by hand for every superset. From what I can see, this has never been done in PHP before, and my coworker's framework will be the first to do so, unless someone can point me towards one that does.

And, also, of course I never load data in constructors, and I only call the load() methods that I create when I actually need the data. However, that is unrelated to this issue, as in this thought experiment (and in the real-life situations where I need to automate this), I always need to eager-load the data of all subsets of children as far down the line as it goes, and not lazy-load them at some future point in time as needed. The thought experiment is concise -- that it doesn't follow best practices is a moot point, and answers that attempt to address its layout are likewise missing the point.

EDIT : Here is a database schema, for clarity.

CREATE TABLE `groups` (
  `group_id` int(11) NOT NULL,  <-- Auto increment
  `make` varchar(20) NOT NULL,
  `model` varchar(20) NOT NULL

CREATE TABLE `groups_users` ( <-- Relational table (many users to one group)
  `group_id` int(11) NOT NULL,
  `user_id` int(11) NOT NULL

CREATE TABLE `users` (
  `user_id` int(11) NOT NULL, <-- Auto increment
  `name` varchar(20) NOT NULL,
  `height` int(11) NOT NULL,

(Also note that I originally used the concepts of wheels and cars, but that was foolish, and this example is much clearer.)


I ended up finding a PHP ORM that does exactly this. It is Laravel's Eloquent. You can specify the relationships between your models, and it intelligently builds optimized queries for eager loading using syntax like this:


It is an absolute life saver. I haven't had to write a single query. It also doesn't work using joins, it intelligently compiles and selects based on foreign keys.

Say you have a "wheel" class, which loads its data from the wheels table in its constructor

Constructors should not be doing any work. Instead they should contain only assignments. Otherwise you make it very hard to test the behavior of the instance.

Now, we have a "car" class, which loads its data from the cars table joined with the cars_wheels table and creates wheel objects from the returned wheel_ids:

No. There are two problems with this.

Your Car class should not contain both code for implementing "car logic" and "persistence logic". Otherwise you are breaking SRP. And wheels are a dependency for the class, which means that the wheels should be injected as parameter for the constructor (most likely - as a collection of wheels, or maybe an array).

Instead you should have a mapper class, which can retrieve data from database and store it in the WheelCollection instance. And a mapper for car, which will store data in Car instance.

$car = new Car;
$car->setId( 42 );
$mapper = new CarMapper( $pdo );
if ( $mapper->fetch($car) ) //if there was a car in DB
    $wheels = new WheelCollection;
    $otherMapper = new WheelMapper( $pdo );

    $car->addWheels( $wheels );

    // I am not a mechanic. There is probably some name for describing 
    // wheels that a car can use
    $otherMapper->fetch( $wheels );

Something like this. The mapper in this case are responsible for performing the queries. And you can have several source for them, for example: have one mapper that checks the cache and only, if that fails, pull data from SQL.

Do I really have to choose between beautiful OOP code with a million queries VS. 1 query and disgusting, un-OOP code?

No, the ugliness comes from fact that active record pattern is only meant for the simplest of usecases (where there is almost no logic associated, glorified value-objects with persistence). For any non-trivial situation it is preferable to apply data mapper pattern.

..and if I make a "city" class, in its constructor I'll need to join the cities table with the cities_dealerships table with the dealerships table with the dealerships_cars table with the cars table with the cars_wheels table with the wheels table.

Jut because you need data about "available cares per dealership in Moscow" does not mean that you need to create Car instances, and you definitely will not care about wheels there. Different parts of site will have different scale at which they operate.

The other thing is that you should stop thinking of classes as table abstractions. There is no rule that says "you must have 1:1 relation between classes and tables".

Take the Car example again. If you look at it, having separate Wheel (or even WheelSet) class is just stupid. Instead you should just have a Car class which already contains all it's parts.

$car = new Car;
$car->setId( 616 );

$mapper = new CarMapper( $cache );
$mapper->fetch( $car );

The mapper can easily fetch data not only from "Cars" table but also from "Wheel" and "Engines" and other tables and populate the $car object.

Bottom line: stop using active record.

P.S.: also, if you care about code quality, you should start reading PoEAA book. Or at least start watching lectures listed here.

my 2 cents

Can you please suggest some books on Software Architecture, which should talk about how to design software at module level and how those modules will interact. There are numerous books which talks about design patterns which are mostly low level details. I know low level details are also important, but I want list of good design architecture book.

Please also suggest some books which talks about case studies of software architecture.

I think this is the book that came to mind when I first read this question. It talks about various architectural styles like pipes-and-filters, blackboard systems, etc. It's an oldie, and I'll let you judge whether it's a 'goodie'.

Pattern Oriented Software Architecture

I also particularly like these two, especially the first. The second starts to dig into lower level design patterns, but it's still awesome in various spots:

Enterprise Integration Patterns

Patterns of Enterprise Application Architecture

I hope these are what you had in mind.

Where can you get knowledge about software architecture? One place is your experience building systems. Another is conversations with other developers or reading their code. Yet another place is books. I am the author of a book on software architecture (Just Enough Software Architecture) but let me instead point you to some classics:

  • Software Architecture in Practice (Bass, Clements, Kazman). This book from the Software Engineering Institute (SEI) describes how architects should think about problems. It describes the importance of quality attributes (performance, security, modifiability, etc.) and how to make tradeoffs between them, since you cannot maximize all of them.
  • Documenting Software Architectures (lots of SEI/CMU authors). The title of this book is a bit scary, because many people are trying to avoid writing shelfware documents. But the wonderful thing about the book is that it describes the standard architectural styles / patterns, notations for describing structure and behavior, and a conceptual model of understanding architectures. All these are valuable even if you only ever sketch on a whiteboard.
  • Software Systems Architecture (Rosanski and Woods). Goes into detail about how to think about a system from multiple perspectives (views). What I like particularly is that it gives checklists for ensuring that a particular concern (say security) has been handled.
  • Essential Software Architecture (Gorton). Small, straightforward book on IT architecture. Covers the different kinds of things you'll see (databases, event busses, app servers, etc.)

That's just a short list and just because I didn't list something doesn't mean it's a bad book. If you are looking something free to read immediately, I have three chapters of my book available for download on my website.

I've seen various MVC frameworks as well as standalone ORM frameworks for PHP, as well as other ORM questions here; however, most of the questions ask for existing frameworks to get started with, which is not what I'm looking for. (I have also read this SO question, but I'm not sure what to make of it as the answers are vague.)

Instead, I figured I'd learn best by getting my hands dirty and actually writing my own ORM, even a simple one. Except I don't really know how to get started, especially since the code I see in other ORMs is so complicated.

With my PHP 5.2.x (this is important) MVC framework I have a basic custom database abstraction layer, that has:

  • Very simple methods like connect($host, $user, $pass, $base), query($sql, $binds), etc
  • Subclasses for each DBMS that it supports
  • A class (and respective subclasses) to represent SQL result sets

But does not have:

  • Active Record functionality, which I assume is an ORM thing (correct me if I'm wrong)

EDIT: to clarify, I only have a database abstraction layer. I don't have models yet, but when I implement them I want them to be native ORM models (so to speak), hence this question.

I've read up a little about ORM, and from my understanding they provide a means to further abstract data models from the database itself by representing data as nothing more than PHP-based classes/objects; again, correct me if I am wrong or have missed out in any way.

Still, I'd like some simple tips from anyone else who's dabbled more or less with ORM frameworks. Is there anything else I need to take note of, simple, academic samples for me to refer to, or resources I can read?

As this question is rather old, I guess you already have had your try at writing an ORM yourself. Nonetheless, as I wrote a custom ORM two years ago, I would still like to share my experience and ideas.

As said I implemented a custom ORM two years ago and even used it with some success in small to medium sized projects. I integrated it in a rather popular CMS which at that time (and even now) lacks such ORM functionality. Furthermore, back then, popular frameworks like Doctrine didn´t really convince me. Much has changed since then and Doctrine 2 evolved in a solid framework, so, if I now had the choice between implementing my own ORM or using one of the popular frameworks like Doctrine 2 for production use, this would be no question at all - use the existing, stable solutions. BUT: implementing such a framework (in a simple manner) was a very valuable learning exercise and it helped me a lot in working with larger open source ORMs, as you get a better understanding for the pitfalls and difficulties associated with object relational mapping.

It is not too difficult to implement basic ORM functionality, but as soon as mapping of relationships between objects come into play, it gets much, much more difficult/interesting.

How did I get started?

What got me hooked was Martin Fowlers book Patterns of Enterprise Application Architecture. If you want to program your own ORM or even if you are just working with some ORM framework, buy this book. It is one of the most valuable resources that cover many of the basic and advanced techniques regarding the field of object relational mapping. Read up on it, you get many great ideas on the patterns behind a ORM.

Basic Architecture

I decided if I would like to use rather an Active Record approach or some kind of Data Mapper. This decision influences on how the data from the database is mapped to the entity. I decided to implement a simple Data Mapper, the same approach as Doctrine 2 or Hibernate in Java uses. Active Record is the approach of the ORM functionality (if you can call it so) in Zend Framework. Active Record is much simpler then a Data Mapper, but also much more limited. Read up on these patterns and check the mentioned frameworks, you get the difference pretty fast. If you decide to go with a Data Mapper, you should also read up on PHPs reflection API.


I had the ambitious goal to create my own query language, much like DQL in Doctrine or HQL in Hibernate. I soon abondoned that, as writing a custom SQL parser/lexer seemed way to complicated (and it really is!). What I did was to implement a Query Object, in order to encapsulate the information which table is involved in the query (thats important as you need to map the data from the database to the relevant classes for each table).

Querying for an object in my ORM looked like this:

public function findCountryByUid($countryUid) {
    $queryObject = new QueryObject();
    $queryObject->addSelectFields(new SelectFields('countries', '*'))
            ->addTable(new Table('countries'))
            ->addWhere('countries.uid = "' . intval($countryUid) . '"');

    $res = $this->findByQuery($queryObject);
    return $res->getSingleResult();


Normally, you also need to have some kind of configuration format, Hibernate uses XML (among others), Doctrine 2 uses PHP annotations, EZComponents uses PHP arrays in its Persistent Object component as config format. Thats what I used, too, it seemed like a natural choice and the CMS I worked with used the PHP configuration format, too.

With that configuration, you define

  • which table gets mapped to which class
  • what fields should get mapped to the class instance
  • what type the fields of the table have (int, string, etc.)
  • the relations between the entities (e. g. a User class has a reference to a UserGroup class)
  • etc.

And thats the information you use in your Data Mapper to map the DB result to objects.


I decided to go with a strong test driven approach, because of the complex nature of writing a custom ORM. TDD or not, writing many, many unit tests is a really good idea on such a project. Apart from that: get your hands dirty and keep Fowlers book close. ;-)

As I said it was really worth the effort, but I wouldn´t want to do it again, much because of the mature frameworks that exist nowadays.

I don´t use my ORM anymore, it worked, but lacked many features, among others: lazy loading, component mapping, transaction support, caching, custom types, prepared statements/parameters etc. And it´s performance wasn´t good enough for using it in large scale projects.

Nonetheless, I hope I could give you some starting points in the field of ORM, if you didn´t knew them already. ;-)

I would like to get book(s) that will really give me a complete view of modern ASP.NET development using C#, TDD, ASP.NET MVC, DDD and Design Patterns such as the Repository pattern. I'm very competent with C# and ASP.NET MVC, but want to fill in the gaps.

If you've had a good experience with a book or two that covers these topics could you please share them?

Try Applying Domain Driven Design and Patterns By Jimmy Nillson. It covers DDD and it's patterns in .NET

Guess the scope of topics you have asked is vast to be covered in a single book

Try this One Agile Principles, Patterns, and Practices in C# By Martin and Martin

Book talks mostly about Design Principles, Design Patters, UML Diagrams, Documentation, Refactoring. It doesn't cover ASP.NET and MVC though. YOu need to refer some other books for those.

I'm currently interested in how to architecture good .NET applications and I'm reading or have currently read some of the following books:

Those two Microsoft books really explain how to design .NET applications with high testability using Inversion Of Control and such.

And to be clear, yes they all use design patterns common in TDD, DDD, Dependency Injection, ans so on...

For your needs I would recommend starting with:

Like the title says; it's basically a book on how to to DDD and TDD in a .NET environment.

Here are a few that I would recommend:

I'm working on a project at the moment that has a rather unusual requirement and I'm hoping to get some advice on the best way to handle it or even some pointers to info that can help me build a solution.

Ok, so this is what I need to do. The application stores and manages various types of media files but each deployment of the application has completely different metadata requirements for the media files.

This metadata can contain an arbitrary number of fields of different types (single line text, multi-line text, checkboxes, selected values, etc.) and also often requires validation particularly presence and uniqueness validations.

The application needs to be able to easily retrieve values and most importantly has to be able to handle full searching capabilities on these fields.

One option I considered was using a property list arrangement where the database table simply contained a property name and value for each metadata field of each media file. However, when prototyping this solution it quickly became apparent that it simply wasn't going to be efficient enough for the searching and retrieval of records particularly when the database can be reasonably large e.g. a recent deployment had 3000 media files and there were over 20 metadata fields. Also, the queries to do a search and retrieve the relevant records quickly became very complex.

Another option that the system is currently using is that the metadata config is defined upfront and a migration is run during deployment to create a the table and model with a standard name so that the media model can be associated with it which the system then uses. This generally works pretty fine but it does cause some significant deployment and testing issues.

For example, writing unit tests becomes much more challenging when you don't know the config until deployment. Although I could write a sample config and test the code that way, it won't allow me to test the specific requirements of a particular deployment.

Similarly, in development, it currently requires me to copy a migration from the config into the main folder, run it, do all of my testing and development and then I have to remember to rollback and remove that migration from the main folder so that the application is in a standard state. This particularly becomes challenging when I'm bug fixing and I need to have the application in a specific configuration for testing and debugging purposes. Trying to switch between the various configurations becomes a real nightmare.

Ideally, what I would like is to be able to dynamically create the table and model including validations, etc. from a config file when the server is started. Even better would be if I could maintain multiple metadata setups in the one database with each one having its own table so that all I need to do to switch between them is change which config file the application is currently using.

I'm sure this can be done with Rails but there is very little information that I've been able to find that can point me in the right direction of how to build it during my research over the past few days so any help or suggestions would be much appreciated!

If I understand you correctly, Rails has some nifty tricks to help you solve these problems.

In the ActiveRecord ORM it's possible to model what you're trying to do in a relational database, either using the single table inheritance pattern, or with polymorphic associations (...a bit more complex but more flexible too). A polymorphic association allows a model to belong_to different types of other models. There's a recent railscast on this topic but I won't link to it since it requires a paid subscription.

On the deployment side, it sounds like you're doing a lot of things manually, which is the right way to start until a pattern emerges. Once you start seeing the pattern, there are excellent programs available for configuration, build, and deployment automation such as Capistrano, OpsCode Chef, and Puppet, to name just a few. You might also benefit from integrating your configuration and deployment with your source code repository to achieve a better workflow. For example, with Git you could define topic branches for the various media file type and have a different configuration in each branch that matches the topic branch.

You may want to check out Martin Fowler's excellent book 'PoEAA' and some of the topics on his website. I hope this answer helps even though the answer is pretty generic. Your question is very broad and does not have one simple answer.

I am a new to professional development. I mean I have only 5 months of professional development experience. Before that I have studied it by myself or at university. So I was looking over questions and found here a question about code quality. And I got a question related to it myself. How do I increase my code understanding/reading skills? Also will it improve the code quality I will write? Is there better code notation than Hungarian one? And is there any really good books for C++ design patterns(or the language doesn't matter?)? Thank you in advance answering these questions and helping me improving :)

P.S. - Also I have forgot to tell you that I am developing with C++ and C# languages.

How do I increase my code understanding/reading skills?

Read read read. Learn from your mistakes. Review answers on SO and elsewhere. When you can think back on a piece of code you wrote and go "aha! I should've done xyz instead!" then you're learning. Read a good book for your language of choice, get beyond the basics and understand more advanced concepts.

Then, apart from reading: write write write! Coding is like math: you won't fully grock it without actually solving problems. Glancing at a math problem's solution is different than getting out a blank piece of paper and solving it yourself.

If you can, do some pair programming too to see how others code and bounce ideas around.

Also will it improve the code quality I will write?

See above. As you progress you should get more efficient. It won't happen by reading a book on design patterns. It will happen by solving real world problems and understanding why what you read works.

Is there better code notation than Hungarian one?

It depends. Generally I avoid them and use descriptive names. The one exception where I might use Hungarian type of notations is for UI elements such as Windows Forms or ASP.NET controls, for example: using btn as a prefix for a Submit button (btnSubmit), txt for a TextBox (txtFirstName), and so on but it differs from project to project depending on approach and patterns utilized.

With regards to UI elements, some people like to keep things alphabetical and may append the control type at the end, so the previous examples become submitButton and firstNameTextBox, respectively. In Windows Forms many people name forms as frmMain, which is Hungarian, while others prefer naming it based on the application name or form purpose, such as MainForm, ReportForm, etc.

EDIT: be sure to check out the difference between Apps Hungarian and Systems Hungarian as mentioned by @Tobias Langner in a comment to an earlier response.

Pascal Case is generally used for method names, classes, and properties, where the first letter of each word is capitalized. For local variables Camel Case is typically used, where the first letter of the first word is lowercase and subsequent words have their first letters capitalized.

You can check out the naming conventions and more from the .NET Framework Design Guidelines. There is a book and some of it is on MSDN.

And is there any really good books for C++ design patterns(or the language doesn't matter?)?

Design patterns should be applicable to any language. Once you understand the concept and the reasoning behind that pattern's usefulness you should be able to apply it in your language of choice. Of course, don't approach everything with a "written in stone" attitude; the pattern is the goal, the implementation might differ slightly between languages depending on language features available to you. Take the Decorator pattern for example, and see how C# extension methods allow it to be implemented differently than without it.

Design Pattern books:

Head First Design Patterns - good beginner intro using Java but code is available for C++ and C# as a download (see "book code and downloads" section on the book's site)

Design Patterns: Elements of Reusable Object-Oriented Software - classic gang of four (GOF)

Patterns of Enterprise Application Architecture - Martin Fowler

If you're looking for best practices for quality coding in C++ and C# then look for the "Effective C++" and "More Effective C++" books (by Scott Meyers) and "Effective C#" and "More Effective C#" books (by Bill Wagner). They won't hold your hand along the way though, so you should have an understanding of the language in general. There are other books in the "Effective" series so make sure you see what's available for your languages.

I'm sure you can do a search here for other recommended reading so I'll stop here.

EDIT: added more details under the Hungarian Notation question.

I'm at a point in my freelance career where I've developed several web applications for small to medium sized businesses that support things such as project management, booking/reservations, and email management.

I like the work but find that eventually my applications get to a point where the overhear for maintenance is very high. I look back at code I wrote 6 months ago and find I have to spend a while just relearning how I originally coded it before I can make a fix or feature additions. I do try to practice using frameworks (I've used Zend Framework before, and am considering Django for my next project)

What techniques or strategies do you use to plan out an application that is capable of handling a lot of users without breaking and still keeping the code clean enough to maintain easily? If anyone has any books or articles they could recommend, that would be greatly appreciated as well.

I'd honestly recommend looking at Martin Fowlers Patterns of Enterprise Application Architecture. It discusses a lot of ways to make your application more organized and maintainable. In addition, I would recommend using unit testing to give you better comprehension of your code. Kent Beck's book on Test Driven Development is a great resource for learning how to address change to your code through unit tests.

I'm building a tiny MVC framework for learning/experimenting and small project purposes. I needed to find out the basics of the internals of the Model since a full MVC framework and ORM is overkill for just a few database calls.

Class Model

Using an empty class where would I have to call a new PDO object for database calls?

What would calling a query look like inside the Model?

Additionally, where can I find a beginner's web/book resource to MVC (with lots of example code)? I've heard a lot of terms such as business logic and database logic. I remember reading somewhere that you should separate business logic and database logic. I can understand the concept somewhat, I just wonder what it looks like or what they mean in code itself. I'm confused how business logic and database logic should be separated but still be inside the Model.

I'm mostly looking for code/logic examples as answers, except maybe the latter paragraph.

The information in this posts is extremely outdated. It represents my understanding of MVC pattern as it was more then 2 years ago. It will be updated when I get round to it. Probably this month (2013.09).

Model itself should not contain any SQL. Ever. It is meant to only contain domain business logic.

The approach i would recommend is to separate the responsibilities, which are not strictly "business logic" into two other other sets of constructs : Domain Objects and Data Mappers.

For example, if you are making a blog, then the Model will not be Post. Instead most likely the model will be Blog , and this model will deal with multiple Domain Objects: multiple instances of Post, Comment, User and maybe other objects.

In your model, the domain objects should not know how to store themselves in database. Or even be aware of the existence of any form of storage. That is a responsibility of Data Mappers. All you should do in the Model is to call $mapper->store( $comment );. And the data mapper should know how to store one specific type of domain objects, and win which table to put the information ( usually the storage of of single domain object actually affects multiple tables ).

Some code

(only relevant fragments from files):

  • I assume that you know how to write a good constructor .. if you have doubts, read this article
  • nothing is namespaced in example, but it should be
  • anything that begins with _ in example is protected

from /application/bootstrap.php

/* --- snip --- */

$connection = new PDO( 'sqlite::memory:' );
$model_factory = new ModelFactory( $connection );

$controller = new SomeController( $request , $model_factory );

/* --- snip --- */


/* --- snip --- */
  • controller does not need to be aware of database connection.
  • if you want to change DB connection for whole application, you need to change single line
  • to change the way how Model's are made, you create different class which implements same interface as ModelFactory

from /framework/classes/ModelFactory.php

/* --- snip --- */

class ModelFactory implements ModelBuilderInterface
   /* --- snip --- */

   protected function _prepare()
      if ( $this->_object_factory === null  )
         $this->_object_factory = new DomainObjectFactory;
      if ( $this->_mapper_factory === null )
         $this->_mapper_factory = new DataMapperFactory( $this->_connection );

   public function build( $name )
      return new {$name}( $this->_object_mapper , $this->_data_mapper );

   /* --- snip --- */

  • only data mappers will use database , only mapper factory need connection
  • all the dependencies of Model are injected in constructor
  • every DataMapper instance in the application uses same DB connection, no Global State (video) required.

file /application/controllers/SomeController.php

/* --- snip --- */

   public function get_foobar()
      $factory = $this->_model_factory;
      $view = $this->_view;

      $foo = $factory->build( 'FooModel' );
      $bar = $factory->build( 'BarModel' );

      $bar->set_language( $this->_request->get('lang') );

      $view->bind( 'ergo' , $foo );

      /* --- snip --- */


/* --- snip --- */
  • controller is unaware of model creation details
  • controller is only responsible for wiring and changing the state of elements

file /application/models/FooModel.php

/* --- snip --- */

   public function find_something( $param  , $filter )
      $something = $this->_object_factory('FooBar');
      $mapper = $this->_mapper_factory('FooMapper');

      $something->set_type( $param );
      $mapper->use_filter( $filter )->fetch( $something );

      return $something;

/* --- snip --- */
  • domain object is responsible for validating the given parameters
  • view receives and decides how to present it
  • mapper takes the object and puts in it all the required information from storage ( it doesn't have to be DB .. it could be taken from some file, or an external REST API )

I hope this will help you understand the separation between DB logic and business logic ( and actually , presentation logic too )

Few notes

Model should never extend Database or ORM, because Model is not a subset of them. By extending a class, you are declaring that has all the characteristics of the superclass, but with minor exceptions.

class Duck extends Bird{}
class ForestDuck extends Duck{}
// this is ok

class Table extends Database{}
class Person extends Table{}
// this is kinda stupid and a bit insulting

Besides the obvious logic-issues, if your Model is tightly coupled with underlaying Database, it makes the code extremely hard to test (talking about Unit Testing (video)).

I personally think, that ORMs are useless and in large project - even harmful. Problem stems from the fact that ORMs are trying to bridge two completely different ways of approaching problems : OOP and SQL.

If you start project with ORM then, after short learning curve, you are able to write simple queries very fast. But by the time you start hitting the ORM's limitations and problems, you are already completely invested in the use of ORM ( maybe even new people were hired , who were really good at your chosen , but sucked at plain SQL ). You end up in situation where every new DB related issue take more and more time to solve. And if you have been using ORM based on ActiveRecord pattern, then the problems directly influence your Models.

Uncle Bob calls this "technical debt".

Few books

loosely related to subject

Recently I came about this concept of Design Patterns, and felt really enthusiastic about it. Can you guys suggest some resources that help me dive into Design Patterns?

You know, for me, one of the best books out there is Head First Design Patterns. I personally like the style that they use to communicate the material.

The gang of four design patterns book is the standard. I recommend it if you're comfortable with C++.

Head first design patterns is good too, especially if you like visual aids and want to feel like you're learning design patterns in a '50s diner. Examples are in Java.

There are sometimes multiple ways to implement patterns in a given programming language (for example see this discussion of options for implementing the Singleton pattern in C#), so it might be worth getting one book to succinctly describe the common patterns, and another to suggest the best way to implement them in your favorite language.

Martin Fowler's website has plenty of information: Much of this is covered also in his book, Patterns of Enterprise Application Architecture.

I find Design Patterns Explained to be a good introductory text. The Gang of Four book is a reference for those who already understand patterns.

Wikipedia, the Gang of Four book, and if you're specifically interested in C# implementations there's a decent site here.

I have been learning more and more javascript; it's a necessity at my job. We have a web application that uses a lot of javascript and I will be doing more and more every day. I have read bits and pieces about design patterns, but was wondering if someone could just give me a cut and dry example and definition. Are they something that would benefit me? Or is it more high level?

As design patterns are language agnostic, I would recommend reading one of the classic books on the subject. My favourites are:

However, these aren't beginner books by any means and you might get more value out of some of the many web resources and tutorials out there (Wikipedia has some reasonable explanations).

My own experience is that the object model in javascript is a bit trickier to understand than others such as PHP or Ruby and hence, applying design patterns isn't always that easy. Libraries such as Prototype provide functions for making inheritance easier to work with and this makes programming Javascript in an OO way much easier.

I recently used Javascript to implement the Active Record pattern using Prototype, which you can read about more about here if you want:

I have looked at a couple of books and all I have looked at were just discussing the technicalities of OOP. By technicalities I mean, here's a concept, here's some code, now get working. I have yet to see a book that discusses the architectural process, what are the ways of doing this, why doing this is bad, how to actually incorporate design patterns in a real-world project, etc.

Can you recommend a good resource or book? I am mainly programming with PHP but a language-agnostic book/resource would do :)

I've had The Object-Oriented Thought Process on my wishlist for a few months, but I haven't got my hands on it yet. The reviews and snippets I've seen are positive, though. You'd need to supplement it with language-specific details from the PHP reference on Classes and Objects, but I think most of the fundamentals should translate well enough, provided you can port the examples.

Edit: Oops. If you're looking for something more advanced, I've also got these two on my list:

I like Craig Larman's Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition). Most PHP programmers would do well to learn habits like design patterns and GRASP.

You could also "keep it in the family" and read the free online book Building Skills in Object-Oriented Design by Stack Overflow top-ten scorer Steven Lott.


Moving from a .NET / SQL Developer role to a more of an architect one. Can anyone reccomend any good books for modern Software Architecture in enterprise?

Appreciate your help.



Domain Driven Design by Eric Evans.

I have been using Rails for over 4 years so obviously I like Rails and like doing things the Rails Way and sometimes I unknowingly fall to the dark side.

I recently picked up Clean Code by Uncle Bob. I am on Chapter 6 and a bit confused whether we as rails developers break the very fundamental rule of OO design, i.e. Law of Demeter or encapsulation? The Law of Demeter states that an object should not know the innards of another object and it should not invoke methods on objects that are returned by a method because when you do that then it suggests one object knows too much about the other object.

But very often we call methods on another object from a model. For example, when we have a relationship like 'An order belongs to a user'. Then very often we end up doing or to prevent it from looking like a train wreck we set up a delegate to do

  1. Isn't that still like breaking the Law of Demeter or encapsulation ?

  2. The other question is: is ActiveRecord just a Data Structure or Data Transfer Object that interfaces with the database?

  3. If yes, then don't we create a Hybrid Structure, i.e. half object and half data structure by putting our business rules in ActiveRecord Models?

Yes, ActiveRecord deliberately breaks encapsulation. This is not so much a limitation of Rails as it is a limitation of the pattern it's based on. Martin Fowler, whose definition of ActiveRecord was pretty much the template Rails used, says as much in the ActiveRecord chapter of POEAA:

Another argument against Active Record is the fact that it couples the object design to the database design. This makes it more difficult to refactor either design as a project goes forward.

This is a common criticism of Rails from other frameworks. Fowler himself says ActiveRecord is mainly to be used

...for domain logic that isn't too complex...if your business logic is complex, you'll soon want to use your object's direct relationships, collections, inheritance and so forth. These don't map easily onto Active Record.

Fowler goes on to say that for more serious applications with complex domain logic the Data Mapper pattern, which does a better job of separating the layers, is preferable. This is one of the reasons that Rails upcoming move to Merb has been generally seen as a positive move for Rails, as Merb makes use of the DataMapper pattern in addition to ActiveRecord.

I'm not sure Demeter is the primary concern with ActiveRecord. Rather I think breaking encapsulation between the data and domain layers breaks Uncle Bob's Single Responsibility Principle. Demeter I think is more a specific example of how to follow the Open/Closed Principle. But I think the broader idea behind all these is the same: classes should do one thing and be robust against future changes, which to some degree ActiveRecord is not.

I want to isolate database code from GUI design. For a reasonable time I've been reading/searching/skimming on topics like mgm/mvp/mvc/persistence/objects etc. I really have difficulty in designing a reusable object hierarchy/framework. Delphi is a great tool for RAD but when you want to work things out in a different way the documentation seems ineffective. I want to develop some king of persistence for data access and wiring data into an object/object list easily. And to integrate data display in a versatile manner (using existing components dbaware or not, create export/import routines for multiple formats). Where should I start? Do you know any tutorials with code? For example mastapp demo included in Delphi installation is a great source for RAD-way as a startup. I need the equivalent in OOP :) with comments & tutorial

As Dispatcher stated, this is a lot of work, but it pays off in the end. I strongly suggest looking at more than one of the existing systems. Don't just settle on the first one you find. Try to understand how they work and how well your vision of your program matches the concepts of the framework.

Get a few good books on patterns. You will find them invaluable as you continue down this path and will be referenced often. I suggest GOF for the basics, and Patterns of Enterprise Application Architecture for the database object model side of things. Most of the concepts in these libraries are based on the patterns discussed in these books.

I was talking with a programmer pal of mine about inheritance and its use in designing models. He's a big proponent and I'm a little more tepid. Mostly because I tend to design systems from the bottom up: Database -> Application -> Presentation (honestly, I'm not much of a front-end guy, so I often leave presentation entirely to someone else). I find that relational database systems don't support inheritance without a lot of 1-to-1 relationships to other tables.

If I'm designing from a conceptual standpoint, an Administrator is a User is a Person. Starting from the database up, an Administrator is a User with UserType = "Administrator". Reconciling these approaches seems difficult to me, and therefore I only use inheritance with non-persisted objects.

What's wrong with my thinking? Why is inheritance such an oft-celebrated aspect of OO if it has these inherent incompatibilities with traditional relational structures? Or, is it me who's not mapping inheritance properly to relational data? Is there some guidance out there that might clear this up for me?

Sorry for the rambling question and thanks in advance for your answers. If you include code in your response, C# is my "native language".

You should read the Patterns of Enterprise Application Architecture. It will show you how inheritance patterns can and should be expressed relational structures.

The important thing to remember is the inheritance is conceptual modelling thing. Relational structures and OO code are just materialisations of those conceptual models, and shouldn't be considered the be all and end all of object orientation.

There is an tutorial on this type of thing here.

I will like to see if everybody could share any good training sources on OOP on PHP language.

Good Training Sources for OOP (Object Oriented Programming) PHP, anyone ?

I've seen numerous tutorials, mostly superficial, some of them bad.

Please share anything good either commercial or free, Video or Written.

It's a bit more on the advanced side of OOP, since it's about design patterns, but I really like Martin Fowler's Patterns of Enterprise Application Architecture ( And you can never go wrong with the Gang of Four's pattern book (

The nice thing about learning patterns is that they're language agnostic. Learn a pattern, use it in (almost) any language :)

Take this simple, contrived example:

UserRepository.GetAllUsers(); UserRepository.GetUserById();

Inevitably, I will have more complex "queries", such as:

//returns users where active=true, deleted=false, and confirmed = true

I'm having trouble determining where the responsibility of the repository ends. GetActiveUsers() represents a simple "query". Does it belong in the repository?

How about something that involves a bit of logic, such as:

//activate the user, set the activationCode to "used", etc.
ActivateUser(string activationCode);

These are all excellent questions to be asking. Being able to determine which of these you should use comes down to your experience and the problem you are working on.

I would suggest reading a book such as Fowler's patterns of enterprise architecture. In this book he discusses the patterns you mention. Most importantly though he assigns each pattern a responsibility. For instance domain logic can be put in either the Service or Domain layers. There are pros and cons associated with each.

If I decide to use a Service layer I assign the layer the role of handling Transactions and Authorization. I like to keep it 'thin' and have no domain logic in there. It becomes an API for my application. I keep all business logic with the domain objects. This includes algorithms and validation for the object. The repository retrieves and persists the domain objects. This may be a one to one mapping between database columns and domain properties for simple systems.

I think GetAtcitveUsers is ok for the Repository. You wouldnt want to retrieve all users from the database and figure out which ones are active in the application as this would lead to poor performance. If ActivateUser has business logic as you suggest, then that logic belongs in the domain object. Persisting the change is the responsibility of the Repository layer.

Hope this helps.

What is the best practise in mapping your database entities to your models and performing business logic? I've seen considerably different implementations of both. I have noticed a number of implementations where the Repository(in the Data Layer) itself is responsible for mapping the database entities to the domain models. For example, a repository that would do this:

public IQueryable<Person> GetPersons()
      return DbSet.Select(s => new Person
                        Id = s.Id,
                        FirstName= s.FirstName,
                        Surname= s.Surname,
                        Location = s.Location,

But having searched comprehensively around SO on N Tier design, I've noticed that while there is no silver bullet, in most situations it's advisable to perform the mapping inside the controller in the MVC project either manually or using a Mapper. It's also been reiterated that the Service layer should never perform the mapping and that it's responsibility should be to perform business logic. A couple of questions here:

  1. Which method is advisable in regards to where to map the entities to models and vice versa? Should the repository do this or should the mapping be done in the controller?
  2. Suppose I want to perform some business logic on the entities that I have retrieved from the database, for example, return the full name of the Person enities, or increase the age of all Persons by 10 years, where should this operation be performed. On the model itself? For example would I have a FullName property on the model which would compute the full name and the age? Or do I define some service inside my service layer to perform business logic?


Wow so many close votes. Apologies, I didn't search comprehensively enough. The 'where to perform business logic' issue I've raised here can already be found on SO and elsewhere (although conveyed somewhat cryptically at times):

Validating with a Service Layer by Stephen Walther

Skinny Controllers

Another great, but more generic answer here on SO

Where Should I put My Controller Business Logic in MVC

Does a Service Map Entities to a View Model

However I'm yet to find a standard solution to the mapping question I had, and I think I could have perhaps expressed my question more eloquently. So the general consensus seems to be that business logic goes in the service layer, and mapping the domain models to view models should take place in the controller/presentation layer. And since it's advisable not to surface your DB entities to any layers other than the Data layer, it's recommended to map your entities to domain models at the data layer either manually or via a mapper such as Auto Mapper (This is what I have gathered from reading many articles). My confusion arose from the question of where should mapping entities to domain models and mapping domain models to view models take place. However as I previously alluded to I could have expressed my question more clearly. The reason for my confusion was that I had read that mapping entities to to domain models should happen in the controller, this should rather be rephrased to say "Mapping entities to domain models should happen at the data later, and mapping domain models to view models should take place in the Controller.

It depends... Like you said there is no a silver bullet. One can only list pros and cons of each approach but still it is you who knows your requirements better than anyone else here. If you have time I suggest reading this book Patterns of Enterprise Application Architecture. This will give you a good understanding about different business logic and data source architectural patterns, when and how to use them. What should go to business layer and what should go to DAL. Also the book addresses the issue of how to map from DAL to Domain entities. You may even change you mind and choose absolutely different approach in the long run.

Also consider using some ORM which provides you with a Code First mechanism like EF Code First or NHibernate. In this case all mapping logic will be transparent to you at all.

What is your advice on:

  1. compensation of accumulated error in bulk math operations on collections of Money objects. How is this implemented in your production code for your locale?
  2. theory behind rounding in accountancy.
  3. any literature on topic.

I currently read Fowler. He mentions Money type, it's typcal structure (int, long, BigDecimal), but says nothing on strategies.

Older posts on money-rounding (here, and here) do not provide a details and formality I need.

Thoughts I found in the inet relate to "Round half even" as the best way to balance error.

Thanks for help.

Wikipedia says:

MVC provides front and back ends for the database, the user, and the data processing components. The separation of software systems into front and back ends simplifies development and separates maintenance.

I still don't see the link between the model-view-controller principle and the idea of front- and backend. Can the Model with its access to the database be seen as the Backend and the View as the frontend?

OK.. first the terms:

  • Frontend - are the parts, which are visible to users: HTML, CSS, client-side Javascript. It all is basically "frontend". In a desktop application frontend would be the GUI.
  • Backend - is the invisible part. In web applications that is your java, ruby, php or any other serverside code. It can be either interpreted or compiled, because "how" it works has no impact on "what" it is.

If you read GUI Architectures and research the MVC pattern in general, you will understand that MVC is not about separation of backend and frontend. Especially when it comes to MVC-inspired patterns, that we use for web applications.

The goal of MVC and related patterns is to separate presentation from domain business logic.

Here are the basic responsibilities of MVC parts:

  • Model - business logic
  • View - presentation logic
  • Controller - changing state of model and view (based on user input)

Let's take an example:

  • alternative client application for twitter
  • uses OAuth for authentication
  • user can input different search phrases
  • takes information via Twitter's REST API
  • validates data
  • parses the JSON responses
  • manipulates DOM to present the information

This all can be done with client-side JavaScript. You can have MVC triad running "frontend"! At the same time, the "backend" which provides REST API is an MVC-like structure. Only this time the View is generating JSON responses, instead of HTML.

*Conclusion: You can use MVC pattern both on backend and frontend.**

Post Scriptum

Since you have been building some applications with Rails, your understanding of MVC might be a but distorted. The reason I say this is because, since RoR was initially made as a prototyping framework (notice all the scaffolding and other features for generating throw-away code), and because of its origin, Rails is actually implementing a very anemic version of MVP.

I call it "anemic", because they nerfed both View (it should be a passive object in MVP, not a simple template) and Model Layer (yes, it is supposed to be a complicated layer, not a collection of ORM instances).

I would recommend for you to read two publications to get a much better grasp on the subject:

The second one is as close as you can get to initial definition of pattern. That, together with "GUI Architectures" article, should provide you a solid footing on the subject. And the PoEAA book (hard read, btw) would give you context in which to expand it.

Having Watched this video by Greg Yound on DDD

I was wondering how you could implement Command-Query Separation (CQS) with DDD when you have in memory changes?

With CQS you have two repositories, one for commands, one for queries. As well as two object groups, command objects and query objects. Command objects only have methods, and no properties that could expose the shape of the objects, and aren't to be used to display data on the screen. Query objects on the other hand are used to display data to the screen.

In the video the commands always go to the database, and so you can use the query repository to fetch the updated data and redisplay on the screen.

Could you use CQS with something like and edit screen in ASP.NET, where changes are made in memory and the screen needs to be updated several times with the changes before the changes are persisted to the database?

For example

  1. I fetch a query object from the query repository and display it on the screen
  2. I click edit
  3. I refetch a query object from the query object repository and display it on the form in edit mode
  4. I change a value on the form, which autoposts back and fetches the command object and issues the relevant command
  5. WHAT TO DO: I now need to display the updated object as the command made changes to the calculated fields. As the command object has not been saved to the database I can't use the query repository. And with CQS I'm not meant to expose the shape of the command object to display on the screen. How would you get a query object back with the updated changes to display on the screen.

A couple of possible solutions I can think of is to have a session repository, or a way of getting a query object from the command object. Or does CQS not apply to this type of scenario?

It seems to me that in the video changes get persisted straight away to the database, and I haven't found an example of DDD with CQS that addresses the issue of batching changes to a domain object and updating the view of the modified domain object before finally issuing a command to save the domain object.

The Unit of Work design pattern from Patterns of Enterprise Application Architecture matches CQS very well - it is basically a big Command that persist stuff in the database.

I am just posting this question so some of you might be able to point me in the right way. I am slowly warming up to OOP, starting to understand the concept. I want to make a good solid core or foundation to be used as a CMS backend. It will also use MVC. I have been using as the MVC- base.

The thing I cant figure out is the following:

Say, on the projectpage in the backend I have 2 sections: htmltext and projects and I should be able to edit them both. The uri would be something like: //domain/backend/projects (the method would be the index and show the 2 sections)

When i click on projects how should it be handled? //domain/backend/projects/projects/ or //domain/backend/projects/list/

One step further, a project will hold some images or a gallery: //domain/backend/projects/edit/5/gallery/2

My question here is, first: would this be a good way to go and even more important how would this be implemented in OOP

the main projects controller:

class projects {

    function index(){
        // view index

    function edit{
        $project = new Project();
        $projectdata = $project->load(5);

A single project controller

class project {

    function __construct(){
        $this->projectmodel = $this->loadModel('project_model'); // prepare the model to be used

    function load($id){

project model

class project_model extends model { //extends for DB  access and such

    function __construct(){
        // do stuff

    function loadproject($id){
        return $this->db->query("SELECT * FROM projects where id=" . $id . " LIMIT 1");

Now my question. If this project has images, where should I load the image class to handle those? Should I load it in the project_model like $this->images = new Images(); and have a function inside the model

function loadimages($id){

and then images would be something like:

class image extends model { //extends for DB  access and such 

    function __construct(){

    function load($id){
        return $this->db->query("SELECT * FROM project_images where id=" . $id . " LIMIT 1");

It seems controllers and models gets mixed up this way. Yet in a logical way a project is a container that holds projectinfo, which could be text, images and maybe video's. How would I go about to set that up logically as well.

The original question

The first part, about the URLs is something called: Routing or Dispatching. There is quite good article about it in relationship with Symfony 2.x, but the the idea behind it is what matters. Also, you might looks at ways how other frameworks implement it.

As for your original URL examples, galleries will be stored in DB. Won't they? And they will have a unique ID. Which makes this, /backend/projects/edit/5/gallery/2 quite pointless. Instead your URL should look more like:

/backend/gallery/5/edit         // edit gallery with ID 5
/backend/project/3              // view project with ID 3
/backend/galleries/project/4    // list galleries filtered by project with ID 4

The URL should contain only the information you really need.

This also would indicate 3 controllers:

  1. single gallery management
  2. single project management
  3. dealing with lists of galleries

And the example URLs would have pattern similar to this:


Where the /backend part is mandatory, but the controller is optional. If controller is found , then id ( or page, when you deal with lists ) and action is optional. If action is found, additional parameter is optional. This structure would let you deal with majority of your routes, if written as a regular expression.

OOP beyond classes

Before you start in on using or writing some sort of PHP framework, you should learn how to write proper object oriented code. And that does not mean "know how to write a class". It means, that you have to actually understand, what is object oriented programming, what principles it is based on, what common mistakes people make and what are the most prevalent misconceptions. Here are few lecture that might help you with it:

This should give you some overview of the subject .. yeah, its a lot. But is suspect that you will prefer videos over books. Otherwise, some reading materials:

You will notice that a lot of materials are language-agnostic. That's because the theory, for class-based object oriented languages, is the same.


Be careful with extends keyword in your code. It means "is a". It is OK, if class Oak extends Tree, because all oaks are trees. But if you have class User extends Database, someone might get offended. There is actually an OOP principle which talks about it: Liskov substitution principle .. also there is a very short explanation

I've studied and implemented design patterns for a few years now, and I'm wondering. What are some of the newer design patterns (since the GOF)? Also, what should one, similar to myself, study [in the way of software design] next?

Note: I've been using TDD, and UML for some time now. I'm curious about the newer paradigm shifts, and or newer design patterns.

I'm surprised that no one has mentioned Martin Fowler's book Patterns of Enterprise Application Architecture. This is an outstanding book with dozens of patterns, many of which are used in modern ORM design (repository, active record), along with a number of UI layer patterns. Highly recommended.

The last few days, I have extensively read books and web pages about OOP and MVC in PHP, so that I can become a better programmer. I've come upon a little problem in my understanding of MVC:

Where do I put a mysql_query?

Should I put it in the controller and call a method on a model that returns data based on the provided query? Or should I put it in the model itself? Are both of the options I'm providing total garbage?

Materials on the subject of MVC

You could have listed the books you were reading, because most (if not all) php books, which touch on MVC, are wrong.

If you want to become a better developer, i would recommend for you to start with article by Marting Fowler - GUI Architectures. Followed by book from same author - "Patterns of Enterprise Application Architecture". Then the next step would be for you to research SOLID principles and understand how to write code which follows Law of Demeter. This should cover the basics =]

Can I use MVC with PHP ?

Not really. At least not the classical MVC as it was defined for Smalltalk.

Instead in PHP you have 4 other patterns which aim for the same goal: MVC Model2, MVP, MVVM and HMVC. Again, I am too lazy to write about differences one more time, so I'll just link to an old comment of mine.

What is Model ?

First thing you must understand is that Model in MVC is not a class or an object. It is a layer which contains multitude of classes. Basically model layer is all of the layers combined (though, the second layer there should be called "Domain Object Layer", because it contains "Domain Model Objects"). If you care to read quick summary on what is contained in each part of Model layer, you can try reading this old comment (skip to "side note" section).

                            Model layer consists of all the 3 concentric circles
The image is taken from Service Layer article on Fowler's site.

What does the Controllers do ?

Controller has one major responsibilities in MVC (I'm gonna talk about Model2 implementation here):

Execute commands on structures from model layer (services or domain objects), which change the state of said structures.

It usually have a secondary responsibility: to bind (or otherwise pass) structures from Model layer to the View, but it becomes a questionable practice, if you follow SRP

Where do I put SQL related code ?

The storage and retrieval of information is handled at the Data Source Layer, and is usually implemented as DataMapper (do not confuse with ORMs, which abuse that name).

Here is how a simplified use of it would look like:

$mapper = $this->mapperFactory->build(Model\Mappers\User::class);
$user = $this->entityFactory->build(Model\Entities\User::class);


if ($user->isBanned() && $user->hasBannExpired()){


As you see, at no point the Domain Object is even aware, that the information from it was stored. And neither it cases about where you put the data. It could be stored in MySQL or PostgreSQL or some noSQL database. Or maybe pushed to remote REST API. Or maybe the mapper was a mock for testing. All you would need to do, to replace the mapper, is provide this method with different factory.

Also, please see these related posts:

There are numerous ways to connect and interact with the database layer. In Java, for example, common usages are JDBC calls of raw SQL, object relational mappers, JDBCTemplate (Spring), stored procedures, etc.

In your language, which option is your preference and why? When would you consider the others?

ActiveRecord, which is a pattern documented first (I think) in Fowler's Patterns of Enterprise Architecture. I believe it's implemented in languages other than Ruby, although it's well-known as a core technology in Rails. Whatever, it's a neat abstraction of the database, although I have to confess that I find it a bit clunky and in the find_by_sql area. But that may just be me.

But (putting on Grumpy Old Man hat now) all the ORMs in the world are no substitute for a good knowledge of SQL, without which I really don't like to see access to an RDBMS being permitted at all.

As I understand it, a UnitOfWork class is meant to represent the concept of a business transaction in the domain. It's not directly supposed to represent a database transaction, which is a detail of only one possible implementation.

Q: So why does so much documentation about the Unit of Work pattern refer to "Commit" and "Rollback" methods?

These concepts mean nothing to the domain, or to domain experts. A business transaction can be "completed", and therefore the UnitOfWork should provide a "Complete" method. Likewise, instead of a "Rollback" method, shouldn't it be modeled as "Clear"?


Answer: Both answers below are correct. Their are two variants of UoW: object registration and caller registration. In object registration, Rollback serves to undo changes to all in-memory objects. In caller registration, Rollback serves to clear all recorded changes such that subsequent call to Commit will do nothing.

The Unit of Work design pattern, at least as defined by Fowler in Patterns of Enterprise Application Architecture - is an implementation detail concerning object-relational persistence mapping. It is not an entity defined in Evans' Domain Driven Design.

As such, it should neither be part of the business discussion, nor an entity that's directly exposed in a domain model - perhaps excepting the commit() method. Instead its intent is tracking "clean" and "dirty" business entities - the objects from a domain model exposed to clients. The purpose is allowing multiple interactions - in web context requests - with a domain model without the need to read and write from persistence (usually a database) each time.

Business entities call it when their methods are called. When their state is altered, they register themselves as dirty with the Unit of Work. Then the Unit of Work's commit() handles the entire persistence transaction in terms of writing out the object graph and rollback() means restoring the state of entities to what they were. So its very much the implementation leaking through to the "abstraction", but its intent is very clear.

On the other hand, "Undo" and "Complete" don't necessarily map one-to-one with this definition. An "Undo" or "Clear" may only rollback an object graph partially for instance depending on the business context. While "Complete" may well be altering state on some entity as well as committing the graph. As such I would put these methods, with business meaning, on a Service Layer or Aggregate Root object.

I have identified below layers to be implemented in my application. According to my knowledge multi layered architecture is prefered for an enterprise application.

  • Presentation Layer
  • Business Layer
  • Data Access Layer
  • Service Layer

I have chosen Symfony2 as the framework to be used in the app. Symfony2 has MVC architecture built into it. And the above layers exist as below.

  • Presentation Layer => Controller & Views
  • Business Layer, Service Layer => Model
  • Data Access Layer => Also Model but Doctrine is used.

Model is consisted with Business Layer, Data Access Layer, Service Layer. See the below image that is borrowed from Martin Fowler's book, Patterns of Enterprise Application Architecture.

Diagram of service layer, with concentric circles

My problem is,

is there a way to decouple the model into separate Business Layer, Data Access Layer, Service Layer ? How to implement multi Layered architecture in PHP ? Should I use some other framework(If only it supports layered architecture) ?


Below link was helpful

How should a model be structured in MVC?

How to build n-layered web architecture with PHP?

What is difference of developing a website in MVC and 3-Tier or N-tier architecture?

MVC application. How does mult-tier architecture fit in?

Implementing a service layer in an MVC architecture

Achieving 3-tier architecture with Symfony PHP

If you are serious about even trying to make something MVC-inspired, then your only options are Synfony and Zend. The others are just sad Rails-clones, that implement some bastardization of PAC. And Sf2.x seems to better one of two .. but that's like pointing out smartest kid in the remedial class.
Unless you are able and willing to make your own framework, Sf2.x will be your best bet.

I think the main problem here is the misunderstanding what "model" in MVC is. Model is a layer, not any specific class or object. In the picture from Fowler's book, the "MVC model" will be all three concentric circles taken together.

You basically have two major layer in MVC: model layer and presentation layer. The presentation layer interacts with model layer through services, that let you abstract the underlaying domain business logic.

Do not confuse it with "domain model". Domain model is an idea that describes all the knowledge and expertise from client's business, that is used in creation of application. Usually it will be represented as separate domain objects and the interaction of said objects.

Also, this picture is somewhat misleading. The data abstraction layer (usually implemented as collection of data mappers) is not lower level structure then domain model. Both domain objects and storage abstractions are uses by service (either directly or through repositories & units of work). It is referred to as "application logic" and is a direct responsibility of services.

Bottom line: no, you do not need to pick some different framework. You only need to learn more about application architecture. You should read Patterns of Enterprise Application Architecture .. that would be a good place to start.

My 2 cents

I've been tasked with adding a website builder to our suite of applications. Most of our clients are non technical small business owners (brick and mortar stores, mom and pop shops). I've been told that I should be looking at Blogger Template Editor and trying to see if I can make something that fully featured and easy to use. The idea being that our customers should be able to bring their business online without knowing anything about web development.

I mostly work with c# and silverlight on a day to day basis. So going with .net is likely the best way for me. ASP.NET MVC and SPARK look very attractive, but I am not too sure about how I will accomplish the following things

1- How do I build a templating system that allows a designer to create templates that use a certain format and are compatible with my app. Is there any generic framework out there for this?

2- How would I persist the changes the client makes to his/her site (for example the client changes the background color and adds a list of ingredients on a page).

Edit: Yes I am aware this is a big task and I am potentially looking at writing a fullblown CMS, however our clients need very limited and basic functionality to begin with and I imagine this would be an iterative process, with perhaps more developers coming on later if the product proves to be successful. I will make these concerns known to our manager though.

Initially I am planning on just giving them a few templated layouts and allow them to customize what goes in the various sections as well as the colors and images with CSS. HAML and Sass look like they could be useful and I could persist all user customizable parameters in a database.

Am I thinking along the right lines or completely off the mark here?

You've effectively been given the task of writing a full blown Content Management System. This is a mammoth task that would probably take a lone developer anything from 6 - 24 months to build depending on experience (this based on development time of other CMS' on the market). For instance, the developers of Umbraco (an Open source ASP.NET CMS) are busy porting their CMS over to ASP.NET MVC, work started around beginning of this year and is not expected to be built until middle of next year, and they're some of the most talented devs in the industry.

I'm not doubting your talents, but unless your boss has given you a very large time scale to work to, or you plan on your website builder being extreme basic with minimal features, perhaps building a full blown Website builder or CMS is biting off more than you can chew.

As other posters have recommended, you should perhaps try existing CMS on the market such as Umbraco if you're a .NET developer.

If you do insist on building your own, it will need some serious planning. Look at software architectural design patterns such as DDD (Domain Driven Design), SOLID principles such as Dependency Injection, the Repository Pattern, Persistance Ignorance, Service Layers etc etc. MVC is definitely the right way to go. Also check out Martins Fowler's book Patterns of Enterprise Application Architecture or Dino Esposito's Microsoft .NET: Architecting Applications for the Enterprise or Eric Evans Domain-Driven Design: Tackling Complexity in the Heart of Software

Originally there was the DAL object which my BO's called for info and then passed to UI. Then I started noticing reduced code in UI and there were Controller classes. What's the decent recomendation.

I currently structure mine

Public Class OrderDAL

    Private _id Integer
    Private _order as Order

    Public Function GetOrder(id as Integer) as Order

        ...return Order

    End Function

End Class

then I have controller classes (recently implemented this style)

Public Class OrderController

    Private Shared _orderDAL as new OrderDAL

    Public Shared Function GetOrder(id) As Order

        Return _orderDAL.GetOrder(id)

    End Function

End Class

Then in my application

My app Sub

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click


    End Sub

End app

I originally found that with the Shared Class I didn't have to keep creating a new instance of the DAL whenever I need to fetch data

Dim _orderDAL as New OrderDal



What's your take?


I think there are several alternatives listed in this excellent book: Patterns of Enterprise Application Architecture. Some patterns that may be of interest to you:

The backend of the company's internal system is getting complicated and I would like to explore the idea of doing a SOA style architecture instead of a heavy monolithic system. Where shall I start?

I'm new to SOA. Does it mean... individual CF instances, and they talk to each other through remote web-services calls? How would one deal with things like... error handling and server outage? Would an ESB be beneficial to the architecture if every part of it are in ColdFusion?

How about the DB layer? Should they share one huge DB or should they store things in their own way themselves?

Thank you

First, what are you trying to accomplish? SOA is useful for systems that need to change relatively easily and be accessible to a new programmer. On the other hand you tend to have a performance tradeoff because you end up segregating persistence - so that its interaction happens on the application server rather than in the database. Usually this performance tradeoff is a non-issue, but if you're working on a high through put transactional system you may need to compromise by putting some algorithms in the database and having those violate your services breakdown.

So if you want the pros and are not particularly concerned with the cons, start by reading some applicable books on the topic:

What you want to trend towards is a design with high level service objects whose relationships are managed via dependency injection through a service locator container. In ColdFusion's case ColdSpring is an example. This then allows for object mocking so you can unit test easily. For example, if the services live on other servers, then the have service objects locally that are proxies to be passed in as dependencies. For testing these proxies are mocked so they don't have to talk to the remote server.

Regarding error handling and server outages. I'm assuming you are primarily concerned about dealing with issues outside of the local server's control. This is another reason use a service proxy object. Have this object be responsible for dealing with timeouts, bad response values and the like - effectively an anti corruption layer.

As for database sharing, I would construct my table relationships to reflect my service object relationships. So if the tables in question have data that only relates through services I would not enforce any foreign key constraints. So while they could be in the same database, it doesn't matter. This enables you to move those services and database tables elsewhere with relatively little change to code.

this my first question on here. I hope someone can help.
It is to do with good object oriented design practices.
I am writing an android app, but the question is a general one and would apply equally to (e.g.) a swing user interface.
For the sake of argument, say I have a class Student.

public class Student {
    public int StudentID;
    public String firstName;
    public String lastName;

There is a principle that you should rarely ask an object for information about itself, rather you should tell it what you want it to do, and let the object do the work itself. To this end, I have the following methods

public class Student {
    public int StudentID;
    public String firstName;
    public String lastName;

    // Constructors
    public Student () {}

    public Student (int StudentID){
        populateFromDataBase (StudentID);

    private void populateFromDataBase (int StudentID){
        // Get the data from the database and set the 
        // values of all the properties of this

    public void save (){
        // Save the values of the properties to db


This is so that other classes may use this class without caring how it persists it's information.
Disclaimers: I know I am not using accessors, just public properties. I'm just trying to keep this example simple.
Don't ask how an external class would know a StudentID, That's irrelavent to the question I want to ask, which is this:

(Say) I want to draw a table of students and their details to the screen. From the UI class (Say a ListActivity in android) I could get an array of students, then loop through them, setting the properties of my ListView as I go. The problem I have with that is that I seem to be thinking far too procedurally, and not in the true spirit of object oriented design. It also requires asking each student object about itself, violating encapsulation.
Apparently (from what I read) the student should draw itself.
Here's where I get confused. How can a student draw itself when it knows nothing of the UI? Do I pass a reference to the UI to the student object? Does this break the separation of presentation and business layers or not? What is considered good practice? Are there any articles or design patterns out there, preferably with example code, because I could not find any? Am I worrying about something not that important and should I just go with my first messy idea?
I really would appreciate any input, as clearly this is an issue that will reoccur with anything that I code.

Another possibility I considered was accessing the database directly from the UI and binding to a cursor, but that just seems wrong. or is it?

Opinions may vary, but IMHO, objects should not draw themselves or for that matter, save themselves to database.

For drawing, I would generally implement some form of double dispatch, such as the Visitor Pattern.

For separation from the UI, you should also consider Model-View-Controller, Model-View-Presenter or Model-View-ViewModel.

Persistence of objects can be rather more complex, and might involve assorted patterns, as described in Martin Fowler's Patterns of Enterprise Application Architecture and summarized at Fowler's website catalog.

And of course, the UI should not bypass the model and go straight to the database.

When designing business objects I have tried several different methods of writing the data access layer. Some have worked out better than others but I have always felt there must be a "better" way.

I would really just like to see the different ways people have handled the DAL in different situations and their opinon of how the technique worked or didn't work well.

Unfortunately I don't think there is a "better way", it's too dependent on the specific situation as to what DAL approach you use. A great discussion of the "state of the art" is Patterns of Enterprise Application Architecture by Martin Fowler.

Chapter 10, Data Source Architectural Patterns specifically talks about most of the most commonly used patterns for business applications.

In general though, I've found using the simplest approach that meets the basic maintainability and adaptability requirements is the best choice.

For example on a recent project a simple "Row Data Gateway" was all I needed. (This was simply code generated classes for each relevant database table, including methods to perform the CRUD operations). No endless debates about ORM versus stored procs, it just worked, and did the required job well.

There are several common patterns. 'The patterns of enterprise architecture' book is a good reference for these:

  • Table Data Gateway
  • Row Data Gateway
  • Active Record
  • Data Mapper

If you use an ORM, such as llblgen, you get the choice of self-servicing or adaptor.

Anyone have a code review checklist/guidelines for a Java web application? A review checklist for each layer would be great.

If there is no such source on the internet, do you know of any good books? I found some useful tips in "Expert One-On-One..." by Rod Johnson. Any other good books you recommend?

In a respones to a question in the same area that I've ased, someone suggested the book Patterns of Enterprise Application Architecture by Martin Fowler. I've yet to read, but it seems to have good reviews.

Can someone send me an article or a book where i can find how to use design patterns inside UML class diagrams? Extra points for references having a case study and a summary about how to use design patterns throughout the UML class diagram.

How can i start with the class design before starting the development of a large application (both WinForm and WebApp). What are the initial 'be-careful' things i should check before designing the class structures?

How to identify the usage of interfaces, abstract classes, delegates, events etc in my application design?

A thorough answer to this question would require a book, not a StackOverflow post! In fact, there are quite a few books about this already, like Martin Fowler's Patterns of Enterprise Application Architecture. Here are some general pointers:

  • Make sure you understand the portion of the problem domain that you're working on. Have you talked to your customers to run things by them first? Does your domain model match the way they think about the world?

  • Statistically speaking, your application is unlikely to be special. That means that if someone insists that they need a particular architecture or implementation pattern for things to work (e.g. an enterprise service bus, message queues, etc.), you should view it with a skeptical eye. Consider whether another approach might not be better.

  • Isolate unrelated portions of the application from each other structurally as well as logically. Don't just loosely couple or decouple your classes; make them entirely separate projects that must be built separately.

  • Code to interface, not implementation. If a number of classes all do something similar, make an interface. Don't use abstract base classes as pseudo-interfaces. Depend on the interface and pass that around instead of the individual implementing classes.

  • Understand the larger scope of the application. What business purpose does it serve? How will it help people, accomplish goals, or improve productivity? Are the things that you're building aligned with that purpose? Make sure you're not building for the sake of building.

  • Be wary when someone tells you that this is an "enterprise application". This is a loaded term with too many connotations for too many different people. Make sure to be clear about cross-cutting concerns like security, authorization, authentication, service guarantees, et cetera.

  • Enterprise applications are prone to bloat. Don't be afraid to say "no" to new features, and refactor mercilessly with good unit tests to make sure you're getting the most bang for your buck.

  • Finally, everything in moderation. Taking any of the above (or anything in general, really) to an extreme is a bad idea. The only thing you should really do in the extreme is moderation itself! :)

I am asking this question because of Zend Framework. I really like it but still the way it offers modularity is not really flexible. For instance a lot of us at first create default and admin module , but in reality it is not reusable. In fact admin should be not a module but some paradigm that takes care of every single module's admin side (like a plug-in manager).

So, anyhow, is there are Good book on Architecture of Modular Web Application?

P.S. sorry if this is a duplicate.

Yes, there are several. But there is only one that is an absolute must read in the web framework world:

Patterns of Enterprise Application Architecture:

It is the de facto standard book with all patterns used through Zend Framework, and almost all other web frameworks. The Front Controller, the Router, the Service Layer, they all come from this book.

You can find a good summary on the web at Fowler's site

Take a look at Zend Framework 1.8 Zend Application Development.

There is a chapter about creating administration module, which is something you called 'some paradigm…'.

I am building a custom MVC framework using PHP. My problem is when I want to access any model class through the controller class. One way I have seen this done is through a registry design pattern using magic methods such as get and set, though PHP get and set are considered bad practise by some. I have read about dependency injection done through a container, but I can not see this working effectily as the container would have to call the models or it would have to contain the models which would defeat the purpose of MVC and create a massive super class. Singleton is seen as bad practise. Is there any solutions or improvements of the methods I have mentioned. It may just be my understand and knowledge of PHP needs improving.

Currently I have this: router.php (loads up controllor through a GET varible


class router {

function __construct() {

    if (file_exists("controller/".$_GET['url']."Controller.php"))  {

       function __autoload($controller) {

           $controlinclude = "controller/".$controller.".php";
            include $controlinclude;

       $control = $_GET['url']."Controller";
        new $control();

    else    {

        // throw exception



Hope that makes sence

First of all ... Do no put autoloading script in routing mechanism. You are mixing the responsibilities. You will be better off creating a separate class for this based on spl_autoload_register.

Neeext .. do no put complicated operations on constructor. It is makes you code somewhat untestable. Maybe you should be something like:

// you might want to replace $_GET with $_SERVER['QUERY_STRING'] later
$router = new Router( $_GET['url'] );

// where 'default' is the name of fallback controller
$controller_class = $router->get_controller( 'default' );
$method_name = $router->get_action( 'index' );

$model_factory = new ModelFactory( new PDO( ... ) );
$controller = new {$controller_class}( $model_factory );

Additionally, you should look into php namespaces. There is no point in ending class with ...Controller just to know where the class will be located.

Ok ... back to the Model.

There is quite common misconception about models in web development community ( i blame RoR for this mess ). Model in MVC is not a class, but an application layer which contains multitude of instances. Most of the instances belong to one of two types of classes. With following responsibilities:

  • Domain Logic :

    Deals with all the computation, calculation and all the domain specific details. Objects in this group have no knowledge of where and how data is actually stored. They only manipulate the information.

  • Data Access

    Usually made of objects that fit DataMapper pattern (do not confuse with ORM of same name .. nothing in common). Responsible for storing data from Domain Objects and retrieving them. Might be in database.. might not. This is where your SQL queries would be.

In semi-real world situation () it might looks something like this (related to code abowe):

class SomeController
   // ... snip ...
   protected $model_factory = null;
   // ... snip ...

   public function __construct( ModelFactory $factory )
       $this->model_factory = $factory;
   // ... snip ...

   public function action_foobar()
      $user = $this->model_factory->build_object( 'User' );
      $mapper = $this->model_factory->build_mapper( 'User' );


      if ( $user->hasWarning()  )
          $user->set_status( 'locked' );

      $mapper->store( $user );

   // ... snip ...

As you see, there is no indication how the data was stored. It does not even matter if user account was new, or already existing.

Some materials you might find useful



I am trying to enhance my knowledge in "design" aspects of Software (engineering), and I am more into Java world.

The first thing I came across was GoF book, which as per my understanding is the "core" or "foundation" design patterns (please correct if i am wrong in interpreting it).

I came across the following terms as i try to go in depth for getting the knowledge of design (patterns).

1) J2EE design pattern.
2) Patterns of Enterprise application architecture.
3) GoF patterns.

I am bit confused as to why there are many design patters and which is used when? In particular, what is the difference between the patterns in #1 and #2?

Any explanation in simple words would be of great help.

Just as there are many books on programming, there are many books on patterns; so the simplest answer to, "what is the difference" is: those three books were written by different authors.

  1. J2EE Design Patterns, –William Crawford
  2. Patterns of Enterprise Application Architecture, –Martin Fowler
  3. Design Patterns: Elements of Reusable Object-Oriented Software, –Erich Gamma, et al.

The GoF book (3) was the first to apply the concept of patterns to software engineering, so in that sense, I think most people would agree that it was the "foundation" for subsequent, pattern-related work.

Do note that architectural patterns and design patterns are separate concepts, as architecture and design represent different levels of abstraction (architecture being a higher level).

Any detailed explanation of when to apply each of these patterns would require a much longer format than SO (hence the aforementioned authors' motivation to publish books) however, most if not all common patterns will have numerous individual threads on SO.

Finally, a key difference in J2EE Patterns is that they are language specific (Java) whereas the other two books are language agnostic.

I have a method in MyWebpage.aspx.cs lik so:

public partial class MyWebpage : PageBase
    private readonly DataAccessLayer dataAccessLayer;

    protected string GetMyTitle(string myVar, string myId)
        if (string.IsNullOrEmpty(myVar))
            return string.Empty;

        return dataAccessLayer.GetMyTitle(Convert.ToInt32(myId), myVar);

In the DataAccessLayer class, I have a methoud that talks to the DB and does the DAL stuff and returns the title.

What's the best practice on accessing the DAL from MyWebPage.aspx.cs class (as in do I need to create a new DataAccessLayer() object each time? Where should I create it in my PageBase class or everytime I call it in a code behind?

First thing is accessing DAL from your code behind or presentation layer generally is not a good practice. Because in this case you need to put your Business logic code in your code behind(Presentation Layer) which causes conflicting of concerns, high coupling, duplication and many other issues. So, if you're look for the best practices, I suggest to have a look at the following links:

And these are really good books:

Also about having static function for calling the DAL. As you know static functions are vulnerable to the multi-threading, so if you are using anything shared in the DAL functions (which its the case sometimes, like shared connection, command etc) it will break your code, so I think it's better to avoid static functions in this layer.

I'm designing this collection of classes and abstract (MustInherit) classes…

class diagram

This is the database table where I'm going to store all this…

database table

As far as the Microsoft SQL Server database knows, those are all nullable ("Allow Nulls") columns.

But really, that depends on the class stored there: LinkNode, HtmlPageNode, or CodePageNode.

Rules might look like this...

rules table

How do I enforce such data integrity rules within my database?

UPDATE: Regarding this single-table design...

I'm still trying to zero in on a final architecture.

I initially started with many small tables with almost zero nullalbe fields.
Which is the best database schema for my navigation?

And I learned about the LINQ to SQL IsDiscriminator property.
What’s the best way to handle one-to-one relationships in SQL?

But then I learned that LINQ to SQL only supports single table inheritance.
Can a LINQ to SQL IsDiscriminator column NOT inherit?

Now I'm trying to handle it with a collection of classes and abstract classes.
Please help me with my .NET abstract classes.

It looks like you are attempting the Single Table Inheritance pattern, this is a pattern covered by the Object-Relational Structural Patterns section of the book Patterns of Enterprise Application Architecture.

I would recommend the Class Table Inheritance or Concrete Table Inheritance patterns if you wish to enforce data integrity via SQL table constraints.

Though it wouldn't be my first suggestion, you could still use Single Table Inheritance and just enforce the constraints via a Stored Procedure.

I'm looking for a good online resource of software patterns. Preferably something with a comprehensive selection and concise well written explanations, not just a collection of links. .Net examples would be nice, but not essential.

Grab this book:

P of EEA By Martin Fowler

Here's the online info of that book

I recommend Head First Design Patterns book from Freemans. These are general design patterns applicable in most OO languages. I recommend this book as an introductory book to design patterns. After this book the GOF book would be another recommendation (but not as a first book).

I'm looking forward to start developing a new server side enterprise communication framework in Java and I'm wondering if anyone knows a good book on the subject? Some best practices and advice would be welcome.


I'm trying to figure out the best way to map inheritance relationships in an object model into a relational database. For example consider the following class structure.

public Class Item 
    public String Name{get; set;}
    public int Size {get; set}    

public Class Widget:Item
    public String Color{get; set;}

public Class Doohicky:Item
    public String Smell{get; set;}

Here's are a few options I'm considering for how to save this structure to a database.

Options 1: Single Table for all item types

Items Table: ItemID, Name, Color, Smell

This sucks as it would require NULL values.

Options 2: Separate tables for each item type

Widgets Table: WidgetID, Name, Color
Doohicky Table: DoohickyID, Name, Smell

This is better, but would be more difficult to list all Items

Options 3: Linked tables

Items Table: ItemID (PK), Name, Size
Widgets Table: WidgetID (PK), ItemID (FK), Color
Doohicky Table: DoohickyID (PK), ItemID (FK), Smell

I think this option is the best, as it prevents me from having Null values in any fields, plus it will make it easier to list all the Items, and/or create a list of a specific type of Item (Widgets or Doohickies).

However, I'm not sure how to create the relationship between the Items table and the Widgets and Doohickies tables. I don't want to end up with row in either table referencing the same ItemID in the Items table.

For example when I add an entry to the Widgets table, how can I ensure that it is linked to a new entry in the Items table with a unique ItemID? Should I instead only track the ItemID rather then separate type specific IDs like WidgetID and DoohickyID, and use it to create a one to one relationships between the Items table and the type specific tables?

Options 4

Items Table: ItemID (PK), Name, Size
Widgets Table: ItemID (PK), Color
Doohicky Table: ItemID (PK), Smell

You're describing Single-Table Inheritance, Concrete Table Inheritance, and Class Table Inheritance.

See the classic Martin Fowler book Patterns of Enterprise Application Architecture for lots of information about them.

One thing you can do to make sure only one sub-type can reference the super-type is to use an ItemType field. A foreign key can reference the columns of a UNIQUE constraint as well as a PRIMARY KEY. So you can add Items.ItemType and make a unique constraint over ItemID, ItemType. The foreign key in each sub-type table references this two-column unique key. And then you can constraint the ItemType in each sub-type table to be a certain value. Then it must match the value in the super-type table, which can only have one value.

Items Table: ItemID (PK), ItemType, Name, Size
  UNIQUE: (ItemID, ItemType)
Widgets Table: ItemID (PK), ItemType, Color
  FK: (ItemID, ItemType)
  CHECK: ItemType=W
Doohicky Table: ItemID (PK), ItemType, Smell
  FK: (ItemID, ItemType)
  CHECK: ItemType=D

In my analysis of the newer web platforms/applications, such as Drupal, Wordpress, and Salesforce, many of them create their software based on the concept of modularization: Where developers can create new extensions and applications without needing to change code in the "core" system maintained by the lead developers. In particular, I know Drupal uses a "hook" system, but I don't know much about the engine or design that implements it.

If you were to go down a path of creating an application and you wanted a system that allowed for modularization, where do you start? Is this a particular design pattern that everyone knows about? Is there a handbook that this paradigm tends to subscribe to? Are their any websites that discuss this type of development from the ground-up?

I know some people point directly to OOP, but that doesn't seem to be the same thing, entirely.

This particular system I'm planning leans more towards something like Salesforce, but it is not a CRM system.

For the sake of the question, please ignore the Buy vs. Build argument, as that consideration is already in the works. Right now, I'm researching the build aspect.

The Plugin pattern from P of EAA is probably what you are after. Create a public interface for your service to which plugins (modules) can integrate to ad-hoc at runtime.

I've searched for a while for a good book which covers server designed patterns. I'm looking for something along the lines of Gang of Four.

Concepts include:

-- Threaded vs Process vs combo based solutions
-- How to triage requests properly. i.e. I expect only limited requests from any domain, so I may only allocate a certain number of workers per domain.
-- Worker timeouts
-- poll/select/epoll use cases
-- And those things I don't know!

Any suggestions please!


Advanced Programming in the Unix Environment, 2nd Edition is a fantastic resource for learning the details of Unix systems programming. It's extremely well-written (one of my favorite books in the English Language), the depth is excellent, and the focus on four common environments (at the time of publication) help ensure that it is well-rounded. It's not too badly out of date -- new features in newer operating systems may be fantastic for specific problems, but this book really covers the basics very well.

The downside, of course, is that APUE2nd misses out on some fantastic third-party tools such as libevent, which can make programming sockets-based servers significantly easier. (And automatically picks the 'best' of select(2), poll(2), epoll(4), kpoll, and Windows event handling, for the platform.)

As for choosing between threads and processes, it comes down to: how much memory sharing do you want / need between tasks? If each process can run relatively isolated, processes provide better memory protection and no speed penalty. If processes need to interact with each other's objects, or objects 'owned' by a single thread, then threads provide better primitives for sharing data. (But many would argue that the shared memory of threads is an invitation to fun and exciting bugs. It Depends.)

Two very useful books:

The book Enterprise Integration Patterns provides a consistent vocabulary and visual notation to describe large-scale integration solutions across many implementation technologies. It also explores in detail the advantages and limitations of asynchronous messaging architectures. You will learn how to design code that connects an application to a messaging system, how to route messages to the proper destination and how to monitor the health of a messaging system. The patterns in the book are technology-agnostic and come to life with examples implemented in different messaging technologies, such as SOAP, JMS, MSMQ, .NET, TIBCO and other EAI Tools.

I want to make a perfect custom DAL (data abstraction layer) class to use with all my projects.

I've searched the internet and found some samples for this but I never know which is the best approach.

Is it to make [Attributes]? Or use <Generics> or something else?

So please just give me a head line and I'll go on from there.

Thanks again and forgive my language.

Definitely don't write your own persistence manager. You should use an Object-Relational Mapper (ORM) if you want to start from a class structure and have the ORM generate the SQL table structures for you, or use an SQL Mapper if you want to start from SQL tables and want to have your classes represent table rows.

I've had great experience using the iBatis SQL Mapper, and a lot of people like Hibernate for an ORM (though there's a learning curve).

Martin Fowler describes several good approaches for writing data access layers in Patterns of Enterprise Application Architecture (here's a catalog).

For instance, iBatis for .NET uses Fowler's Table Data Gateway pattern. In iBatis you specify Table Data Gateway objects in XML. Each Gateway typically governs access to one SQL table, although you can do multi-table operations too. A Gateway is composed of SQL statements, each wrapped in a bit of XML. Each SELECT returns one or more row objects, which are just sets of attributes plus getter and setter methods (in .NET these are called POCOs or PONOs, Plain Old C# Objects or Plain Old .NET Objects.). Each INSERT or UPDATE takes a POCO as its input. This seemed pretty intuitive, and not too hard to learn.

Scenario: You have a reasonably sized project with some forms, classes, etc.

Question: How would you group your functions? Would you put the functions common to all the forms into one separate class or a number of classes depending on function? What about your database calls. Would you have one class that contained all your database functions? Or would your create a utility class that would handle the calls?

Reason: I'm looking for some direction on how to best "group" functions. For instance I can see that having all the database functions in one class would make it easier to change/debug later, but is that necessary? I'm partial to the utility that handles all the connections for you and returns the formatted result but the SQL code does end up all over the place.

End Note: I know there are a lot of questions but as I said I'm looking for direction, you don't have to take every answer and answer it to a T but some coding guidelines or some coding wisdom from past experiences would be greatly appreciated

Many thanks,

Check out 3-Tier Architecture. But if you're looking for something more in depth, there are many great books on the subject of Application Architecture. You could try Patterns of Enterprise Application Architecture.

For a system where a user can be a member or admin, users with the member role must either pay for it with a recurring subscription, or be given a complimentary access.

My current approach:

  • Users have a user database table.
  • A subscription table includes a record for a user if they have a subscription.
  • A subscription_event table records each billing or failed payment. I can query this to see if the last event was indeed a successful payment.

But how should I record if a user is given "complimentary" access?

  • Have another table complimentary_subscription with the user ID as the foreign key?
  • Record a special "subscription" for them in subscription?
  • Or add another column to their user row for columns like is_complimentary and complimentary_expires_date?
  • Add a more general expires column to the user row?

Question Review

As @leanne said, you're modeling a Subscription whose specializations are, say, MonthlySubscription and ComplimentarySubscription (to give them a name for this answer).

You know that a subscription can expire:

  • For a MonthlySubscription, that happens when a user didn't pay the current month's subscription
  • For a ComplimentarySubscription, the expiration date is assigned when it’s assigned to the user

As you can see an ExpirationDate is an essential attribute of any Subscription, but the way you store it is different in each case. If the first case you'll have to calculate it based on the last event, in the latter you can retrieve it directly.

Dealing with Inheritance in the Data Base

So, to map this sample model to a database schema, you could go with the Class Table Inheritance pattern described in Martin Fowler's Patterns of Enterprise Application Architecture book. Here is its intent:

"Represents an inheritance hierarchy of classes with one table for each class".

Basically you'll have a table with the attributes shared in common between the classes, and you'll be storing attributes specific to each class in a separate table.

Keeping this in mind, let's review the options you proposed:

  • Have another table complimentary_subscription with the user ID as the foreign key?

Having a separate table for storing ComplimentarySubscription specific details sound good, but if you don't relate this one with the subscription table, you can end up with an user that has both a MonthlySubscription and a ComplimentarySubscription. Its foreign key should point to the subscription table, which is the one that tells you if a user has a subscription or not (and you'll have to enforce up to one subscription per user).

  • Record a special "subscription" for them in subscription?

Yes, you'll have to record that a user has a subscription either monthly or complimentary. But if you're thinking something like recording a special subscription whose amount is zero, you’re looking for a solution that matches your current design instead of searching for the right model for it (it might and it might be not).

  • Or add another column to their user row for columns like is_complimentary and complimentary_expires_date?

Personally I don't like this one because you're putting information where it doesn't belong. Taking that into account, where you will be storing the expiration date for complimentary subscriptions (remember that for monthly ones you are calculating it, and not storing the expiration date)? It seems that all that information is crying for its own "home". Also, if later you need to add a new type of subscription that table will begin to clutter.

  • Add a more general expires column to the user row?

If you do this, you'll have to deal with data synchronization each time the subscription_event gets changed (in the case of a monthly subscription). Generally I try to avoid this data-duplication situation.

Sample Solution

What I would do to favor extensibility when adding new types of subscription is to have the subscription table to store shared details between MonthlySubscripton and ComplimentarySubscription, adding a type column key that'll let you differentiate which kind of subscription a row is related to.

Then, store details specific to each subscription type in its own table, referencing the parent subscription row.

For retrieving data, you'll need an object in charge of instantiating the right type of Subscription given the type column value for a subscription row.

You can take a look at the pattern in the "Patterns of Enterprise Application Architecture" book for further assistance on how to define the type column values, how to use a mapper object to do the Subscription instantiation and so on.

01/03/2012 Update: Alternatives for defining and handling the type column

Here's an update to clarify the following question posted by @enoinoc in the comments:

Specifically for the suggested type column, could this be a foreign key pointing to a Plans table which describes different types of subscriptions, such as how many months before they expire without payment. Does that sound logical?

It's ok to have that information in the Plans table, as long it´s not static information that doesn´t need to be edited. If that's the case, don't over-generalize your solution and put that knowledge in the corresponding Subscription subclass.

About the foreign key approach, I can think of some drawbacks going that way:

  • Remember that your goal is to know wich subclass of Subscription to use for each row in the Plans table. If all you got is a foreign key value (say, an integer) you'll have to write code to map that value with the class to use. That means extra work for you :)
  • If you have to do unnecesary extra work, it's likely that mainteinance will be a pain: each time you add a new plan, you'll have to remember hardcoding it's foreign key value in the mapping code.
  • Foreign keys might change in case of improper database export/import operations. If that happens, your mapping code will no longer work and you'll have to deploy your software again (or, at least, the part that changed).

Proposed Solution

What I'd do is to put into the type column in the Plans table. That column will hold the name of the class that knows how to build the right Subscription from a particular row.

But: why do we need an object to build each type of Subscription? Because you'll be using information from different tables (subscription_event and complimentary_subscription) for building each type of object, and it´s always good to isolate and encapsulate that behavior.

Let's see how the Plans table might look like:

-- Plans Table --

Id | Name | Type | Other Columns...

1 | Monthly | MonthlySubscriptionMapper |

2 | Complimentary | ComplimentarySubscriptionMapper |

Each SubscriptionMapper can define a method Subscription MapFrom(Row aRow) that takes a row from the database and gives you the right instance of the Subscription subclass (MonthlySubscription or ComplimentarySubscription in the example).

Finally to get an instance of the mapper specified in the type column (without using a nasty if or case statements) you can take the class name from the column's value and, by using reflection, create an instance of that class.

I am designing an API and I would like it to be simple to use. So, if I have Customers, Statements, and Payments. Does it make sense to have objects such as: Customer, CustomerHandler, Statement, StatementHandler, Payment, PaymentHandler? This way when the developer wants to do something with customers he/she knows to create a CustomerHandler and then all of the possible functions that one would like to perform with a customer are inside the handler.

Methods like: CustomerHandler: AddCustomer(customer), GetCustomer(customerID), GetCustomerCount()… StatementHandler: AddStatement(customerID), GetStatement(statementID), GetStatementCount(customerID)… PaymentHandler: GetPaymentsByCustomer(customerID), GetPayment(paymentID), GetPaymentCountByCustomer(customerID)…

This way if the developer wants to work on receiving payments he/she knows to go to the PaymentHandler. My coworker thought that functions like GetPayments(customerID) belong in a class that manages the customer. So, it would be like Customer.GetPayments() AS Payments. But if I have some other entity like Worker, there would be Worker.GetPayments() AS Payments. So, I see the logic with both approaches. The first one groups things together so that if no matter whom the payment is coming from you get it all from one class by having functions like GetPaymentsByCustomer(CustomerID) and GetPaymentsByWorker(WorkerID). This way one does not have to stumble through different handler or manager objects to get payments. Both approaches make sense to me, how about you? Or, are we both off and there is a better way to do this? Thanks in advance!

You are pretty much describing two ways (patterns) for data access:

Please, get Martin Fowler's book Patterns of Enterprise Application Architecture and read through all pros and cons. In particular if you try to expose your objects and APIs as web services you might want to go with the data mapper approach (as you suggest).

Active record is very popular because it is simpler. Decide for yourself what suites your needs the best.

I am developing a transactional application in .NET and would like to get some input on how to properly encapsulate database access so that:

  • I don't have connection strings all over the place
  • Multiple calls to the same stored procedure from different functions
  • or WORSE, multiple stored procedures that are different by a single column

I am interested in knowing if using an ORM like NHibernate is useful, as it may just add another layer of complexity to a rapidly changing data model, and artifacts need to be produced on a tight schedule.

I am more interested in methods or patterns OTHER than ORM packages.

There are at least two widely accepted design patterns used to encapsulate data access:

  • repository (DDD)
  • DAO (Data Access Object)

For the sake of completeness I suggest you these books:

I am looking for a good and short article+examples of how working with interfaces. I am not interesting the technical part, but I need the design part. For example, how to programming using interfaces, when and how create implementations, design patterns for regular development with interfaces.

I have many similar classes that repeat themselves in several ways. I want to use interfaces and abstract classes in order to make things more modular - but I can't find out how to do it properly.

This book as been the canonical reference for design patterns and contains examples of using interfaces. However you may want to start at an even more fundamental level. Thinking in Java is what got me into object oriented programming, there are likely similar titles for C# though the content of the book should be mostly agnostic of the language. You may also search for online tutorials on object oriented programming.

Edit: Great book about patterns and their implementation and usage in C# is C# 3.0 Design Patterns

@Naor, its seems, based on your above comment "It doesn't seem logical to create interface for each class I have - right?" that the best book for you to read is HEAD FIRST; DESIGN PATTERNS - it has an incredible and easy way of teaching how to use an apply design patterns. I first read of them in this book and it has definetly changed my mind!!! By reading this you'll be able to read more complicated stuff like Martin Fowler, Patterns of Enterprise Application Archtecture - which I believe approaches exatcly what you want, real world applicatoins of patterns. Going straight to to GoF, or M. Fowler, or more complicated stuff may disspoint you or make you just lose time.

I am reading the book Patterns of enterprise application architecture. While going through the basic patterns - such as Registry pattern I am finding that possibilities that these patterns which were first published in Nov,2002 may not be the best possible solutions to go for.

For example take the Registry pattern. In our organization we use simple JDBC calls for db operations and if needed pass the connection object for a single transaction. This approach is not the best - but the alternative of using Registry pattern also is not seeming good as the dependency would then not be visible - can be an issue for testing. Dependency Injection is suggested as a better way to implement this behavior.

Can anyone who has worked on Java EE web/enterprise apps comment on this - and what would you recommend to analyze the usage of each pattern (its pros and cons?). Any recent book that does a coverage of this in detail?.

(...) Any recent book that does a coverage of this in detail?

I recommend Adam Bien's Real World Java EE Patterns if you're looking for an up to date coverage of patterns and best practices with Java EE 5 and 6:

Real World Java EE Patterns

Real World Java EE Patterns includes coverage of:

  1. An introduction into the core principles and APIs of Java EE 6 (EJB, JPA, JMS, JCA, JTA, Dependency Injection, Convention Over Configuration, Interceptors, REST)
  2. Principles of transactions, Isolation Levels, Remoting in context of Java EE 6
  3. Mapping of the Core J2EE patterns into Java EE
  4. Discussion of superfluous patterns and outdated best practices like DAOs, Business Delegates, Data Transfer Objects extensive layering, indirections etc.
  5. Business layer patterns for domain driven and service oriented architectures
  6. Patterns for integration of asynchronous, legacy, or incompatible resources
  7. Infrastructural patterns for eager-starting of services, thread tracking, pre-condition checks, Java EE 6 lookups or integration of third-party Dependency Injection frameworks like Guice
  8. Hints for efficient documentation and testing
  9. Lean and pragmatic service and domain driven architectures, based on the discussed patterns
  10. Fully functional Java Connector Architecture (JCA) implementation with source code
  11. EJB 2 - EJB 3 migration

I am writing RESTful services using spring and hibernate. I read many resource in internet, but they did not clarify my doubts. Please explain me in details what are DAO, DTO and Service layers in spring framework? And what are concern use these layers in spring to develop RESTfull API services.

First off, these concepts are Platform Agnostic and are not exclusive to Spring Framework or any other framework, for that matter.

Data Transfer Object

DTO is an object that carries data between processes. When you're working with a remote interface, each call it is expensive. As a result you need to reduce the number of calls. The solution is to create a Data Transfer Object that can hold all the data for the call. It needs to be serializable to go across the connection. Usually an assembler is used on the server side to transfer data between the DTO and any domain objects. It's often little more than a bunch of fields and the getters and setters for them.

Data Access Object

A Data Access Object abstracts and encapsulates all access to the data source. The DAO manages the connection with the data source to obtain and store data.

The DAO implements the access mechanism required to work with the data source. The data source could be a persistent store like an RDBMS, or a business service accessed via REST or SOAP.

The DAO abstracts the underlying data access implementation for the Service objects to enable transparent access to the data source. The Service also delegates data load and store operations to the DAO.


Service objects are doing the work that the application needs to do for the domain you're working with. It involves calculations based on inputs and stored data, validation of any data that comes in from the presentation, and figuring out exactly what data source logic to dispatch, depending on commands received from the presentation.

A Service Layer defines an application's boundary and its set of available operations from the perspective of interfacing client layers. It encapsulates the application's business logic, controlling transactions and coordinating responses in the implementation of its operations.

Recommended References

Martin Fowler has a great book on common Application Architecture Patterns named Patterns of Enterprise Application Architecture. There is also, Core J2EE Patterns that worth looking at.

I have a question. I need to create a little thing to do with products. Now I can have say 7 different types of products. Some are subtypes of others e.g.

 - Vans
   - petrol
   - diesel
 - City
 - Hatchback
 - Saloon
 - Estate
   - petrol
   - diesel

Now, for the sake of the argument all my City, Hatchback and Saloon cars are hybrid/gas/whatever and I do not plan to sell petrol and diesel ones. However there is a possibility that I may have petrol and diesel saloon cars sometime in the future, but it's not like I am going to have 20+ types of products. If it is going to go up I will have probably 2-3 more types.

From what I understand Prototype Pattern may be good one here for I will be able to avoid duplication between estate->petrol and van->petrol ... but then again Van cars will have different characteristics than say city car e.g. maximum loading dimensions.

I have been reading extensively about design patterns and one thing I remember for certain is not to use pattern when you don't need it. Now the question is - do I need it?


The Decorator Pattern is probably the most straight forward one to use and would be a good one to extend concrete objects functionality and/or characteristics.

Here is some light reading: Head First Design Patterns - CH3 pdf

FYI, couple must have's for learning and referencing design patterns regardless your language of choice:

1) Head First Design Patterns

2) Patterns for Enterprise Application Architecture

3) Design Patterns: Elements of Reusable Object-Oriented Software

And sites:

1) DoFactory

2) StackOverflow Design Patterns Newbie

There are a few others, I'll have to dig them up.

I'm building a T4 template that will help people construct Azure queues in a consistent and simple manner. I'd like to make this self-documenting, and somewhat consistent.

  1. First I made the queue name at the top of the file, the queue names have to be in lowercase so I added ToLower()

  2. The public constructor uses the built-in StorageClient API's to access the connection strings. I've seen many different approaches to this, and would like to get something that works in almost all situations. (ideas? do share)

  3. I dislike the unneeded HTTP requests to check if the queues have been created so I made is a static bool . I didn't implement a Lock(monitorObject) since I don't think one is needed.

  4. Instead of using a string and parsing it with commas (like most MSDN documentation) I'm serializing the object when passing it into the queue.

  5. For further optimization I'm using a JSON serializer extension method to get the most out of the 8k limit. Not sure if an encoding will help optimize this any more

  6. Added retry logic to handle certain scenarios that occur with the queue (see html link)

  7. Q: Is "DataContext" appropriate name for this class?

  8. Q: Is it a poor practice to name the Queue Action Name in the manner I have done?

What additional changes do you think I should make?

public class AgentQueueDataContext
    // Queue names must always be in lowercase
    // Is named like a const, but isn't one because .ToLower won't compile...
    static string AGENT_QUEUE_ACTION_NAME = "AgentQueueActions".ToLower();

  static bool QueuesWereCreated { get; set; }

    DataModel.SecretDataSource secDataSource = null;

    CloudStorageAccount cloudStorageAccount = null;
    CloudQueueClient cloudQueueClient = null;
    CloudQueue queueAgentQueueActions = null;

    static AgentQueueDataContext()
        QueuesWereCreated = false;

    public AgentQueueDataContext() : this(false)
    public AgentQueueDataContext(bool CreateQueues)
        // This pattern of setting up queues is from:
        // ttp://
        this.cloudStorageAccount = CloudStorageAccount.FromConfigurationSetting("DataConnectionString");
        this.cloudQueueClient = cloudStorageAccount.CreateCloudQueueClient();
        this.secDataSource = new DataModel.SecretDataSource();

        queueAgentQueueActions = cloudQueueClient.GetQueueReference(AGENT_QUEUE_ACTION_NAME);

        if (QueuesWereCreated == false || CreateQueues)
            QueuesWereCreated = true;

  // This is the method that will be spawned using ThreadStart
   public void CheckQueue()
        while (true)
                CloudQueueMessage msg = queueAgentQueueActions.GetMessage();

                bool DoRetryDelayLogic = false;

                if (msg != null)
                    // Deserialize using JSON (allows more data to be stored)
                    AgentQueueEntry actionableMessage = msg.AsString.FromJSONString<AgentQueueEntry>();

                    switch (actionableMessage.ActionType)
                        case AgentQueueActionEnum.EnrollNew:
                                // Add to 
                        case AgentQueueActionEnum.LinkToSite:
                                // Link within Agent itself

                                // Link within Site

                        case AgentQueueActionEnum.DisableKey:
                                // Disable key in site

                                // Disable key in AgentTable (update modification time)


                    // Only delete the message if the requested agent has been missing for 
                    // at least 10 minutes
                    if (DoRetryDelayLogic)
                        if (msg.InsertionTime != null)
                            if (msg.InsertionTime < DateTime.UtcNow + new TimeSpan(0, 10, 10))

                        // ToDo: Log error: AgentID xxx has not been found in table for xxx minutes.   
                        //                  It is likely the result of a the registratoin host crashing.
                        //                  Data is still consistent.  Deleting queued message.

                    // If execution made it to this point, then we are either fully processed, or 
                    // there is sufficent reason to discard the message.
                    catch (StorageClientException ex)
                        // As of July 2010, this is the best way to detect this class of exception
                        // Description: ttp://
                        if (ex.ExtendedErrorInformation.ErrorCode == "MessageNotFound")
                            // pop receipt must be invalid
                            // ignore or log (so we can tune the visibility timeout)
                            // not the error we were expecting
                   // allow control to fall to the bottom, where the sleep timer is...
            catch (Exception e)
                // Justification: Thread must not fail.
                //Todo: Log this exception

                // allow control to fall to the bottom, where the sleep timer is...
                // Rationale: not doing so may cause queue thrashing on a specific corrupt entry

            // todo: Thread.Sleep() is bad
            //       Replace with something better...

Q: Is "DataContext" appropriate name for this class?

In .NET we have a lot of DataContext classes, so in the sense that you want names to appropriately communicate what the class does, I think XyzQueueDataContext properly communicates what the class does - although you can't query from it.

If you want to stay more aligned to accepted pattern languages, Patterns of Enterprise Application Architecture calls any class that encapsulates access to an external system for a Gateway, while more specifically you may want to use the term Channel in the language of Enterprise Integration Patterns - that's what I would do.

Q: Is it a poor practice to name the Queue Action Name in the manner I have done?

Well, it certainly tightly couples the queue name to the class. This means that if you later decide that you want to decouple those, you can't.

As a general comment I think this class might benefit from trying to do less. Using the queue is not the same thing as managing it, so instead of having all of that queue management code there, I'd suggest injecting a CloudQueue into the instance. Here's how I implement my AzureChannel constructor:

private readonly CloudQueue queue;

public AzureChannel(CloudQueue queue)
    if (queue == null)
        throw new ArgumentNullException("queue");

    this.queue = queue;

This better fits the Single Responsibility Principle and you can now implement queue management in its own (reusable) class.

In MVC, 1 model 1 tables or 1 model several tables?

I am building an application that contain 3 tables. I don't know whether I should create one model for all 3 tables or create 3 models for 3 tables.

In the case I use 3 models for 3 tables, where should I put the code if I want to join these 3 tables? Put the code in any one of 3 models?

Any suggestions?

In general, the 'Model' part of MVC should be interpreted as a 'Presentation Model' or 'View Model' - that is, a class that encapsulates all the data and behavior needed by the View. This may or may not be equivalent to the Domain Model.

Domain Models should be designed to be independent of UI. This means that such Models should not be polluted with UI-specific data and behavior - such as determining whether a particular button is enabled or not.

You may also want to show the same Domain Objects in several different views (e.g. Master/Detail, or Display/Edit), and if those views differ sufficiently, having a View Model for each View will be beneficial.

So, in general, you should design your Domain Layer and your Presentation Layer independently.

In the Domain Layer, you can choose to model your three tables as three classes. Books like Fowler's Patterns of Enterprise Application Architecture and Evans's Domain-Driven Design contains lots of guidance on how to model relational data as Domain Models.

When it comes to modeling the views in MVC, it makes most sense to create one Model per View. Such a View Model might simply encapsulate a single Domain Object, but it may also encapsulate and aggregate several different Domain Objects.

In this way, you can ensure separation of concerns, and that your classes follow the Single Responsibility Principle.

For very simple scenarios, it may make sense to collapse the Domain Model and the Presentation Model into one layer, but you should realize that this essentially means that there's no Domain Model in the solution - all models would be pure Presentation Models.

In my company we have developped some applications. We have to create an API for one application (say application A), so that the others can use it (an its data).

The question is : we already have developped PHP classes for the model of Application A, if we want to create an API, should we :
- re-use these classes (too much functionnalities for an API, too heavy...)
- create one PHP class, with some basic functions, that takes in input and returns only raw values (like strings, array... NOT complex classes)
- create another set of PHP classes, simpler, and designed only to be used by an external application (so only to get data easily)

Usually, an API is the 2nd solution (to be used as well with PHP than as a web service for example), but i find it too bad that we made a complex and usefull class modelisation, then we tear it apart just to have functions, strings and array. The 3rd one seems to me to be the compromise, but a collegue of mine insist that this is not an API. Too bad...

What do you think ?

Solution number 3 might be the best one from an architectural point of view. Basically you are using a Facade Design Pattern to simplify your API. Since I am dealing with it at the moment: In Patterns Of Enterprise Application Architecture this approach is described as the service layer which makes totally sense since you don't want to expose any user (meaning whoever will deal with your API) to more complexity than is actually needed or desired.

This includes using the easiest possible interface and transfer objects (raw values if they make sense). As soon as your Facade is being called through remoting services (like a webservice) you will eventually have to break repsonses and requests down to raw values (data containers) anyway.

In the search for resources to become a better developer, I am looking for good examples of how to structure the code in n-tier applications.

Like... What does the business object do and look, how does it interface with the data access layer etc. How does the UI interface the business layer, and does it interface the DAL directly.

Do you know of great examples freely available, that are worthy of study?

Also, the book Enterprise Application Architechture by Martin Fowler is a must read. Google it or use the amazon link provided. Enterprise Application Architecture on Amazon.

Have a look at this example:, which was developed as the example for this book:

It's .net 2.0 and not perfect, but it's a great example of an n-tier application that makes good use of the provider model. We've adapted the pattern and use if for 90% of our in-house development. Make sure you don't confuse this pattern with the MVC pattern, as they are quite different.

Have a look at the wikipedia article on n-tier architecture: The presentation tier is implemented as pages and user controls in the example I have given, the logic tier (commonly called BLL or business logic layer) is concrete C# classes defining specific behaviour, and the data tier (commonly called DAL or data access layer) is abstract C# classes defining the storage mechanism with concrete C# classes for using Sql Server as the storage medium.

Hope this helps.

I USED to be a developer and part-time db designer, but it's been many years and I'm re-learning...

I'm building a web app and have a Person (actually "Profile") table with a number of child tables which have N:N relationships with my Person table, e.g. FavoriteSports MusicalInstruments ArtisticSkills

After reading through Scott Mitchell's excellent data access tutorials at, I want to design my app w/ well-thought-out Data Access (using Table Adapters) and Business Logic (using Classes) Layers.

Where I get hung up is in designing the Classes and Table Adapters. The "Unit of work" here is something more like a real-life object, that doesn't align directly with my table-based classes or data access objects. So I guess what I'm seeing is a need to build a class modeled not around the tables, but instead around the real-life object (my Profile+FavoriteSports+MusicalInstruments+ArtisticSkills).

What I'm really looking for is a good book or web site that describes how to do this. Specifically, how can I build a class that supports these child records (as collections?). I think I understand the concepts - I just need some guidance on how to put it into practice.

The best answer I could ask for would point me at a book (C#, preferrably) that goes into all this in all its complexities - pretty sure I'm way past the "Beginners" books with this.

Thanks -


Unfortunately one book might not help. I recommend you go for these books to get back to understanding the two worlds of RDBMS and OO. Tables and business entities may not be a 1:1 map!

Patterns of Enterprise Application Architecture

Domain-Driven Design: Tackling Complexity in the Heart of Software

.NET Domain-Driven Design with C#: Problem - Design - Solution

Hope that helps.

I want all my layers BLL ,DAL and UI to share classes (concrete or interfaces).

Is this really a bad practice?

I prefer not to return datatables from my DAL methods but instead to return objects that BLL can use directly.

I want to have a separate VS project with the classes that all layers should know about.

Example: I want to define a lot class that all layers should be aware of. UI should be able to receive lot classes in order to display or make possible for the user to submit a lot to be processed. Also DAL should be able to query the db with lot classes and return them. BLL on the other hand should get these lots and apply business rules onto them.

If this is completely wrong what are the alternatives?

I want all my layers BLL,DAL and UI to share classes (concrete or interfaces).

It depends on what type of classes. If you need them all to access common domain entities, then sure.

The important part is what you allow those layers to do with those classes. Your client/UI layer shouldn't be able to modify the domain entities (and persist them) without going through some centralized business logic. This means your DAL shouldn't be accessible by your UI, although they can both share common entities, interfaces, etc...

A common approach is something like this:

UI -> BLL -> DAL -> Persistence storage (DB, file, etc...)

Each of those layers can access commmon classes. As long the UI can't directly access the DAL, you should be okay. You have a couple of options for this:

  • Make the BLL accessible through a service (WCF, etc...)
  • Put the DAL and BLL in the same project and make the DAL internal so only the BLL can access it

You end up with something like:

UI -> Service -> BLL -> DAL -> Persistence storage (DB, file, etc...)

I would strongly recommend Patterns of Enterprise Application Architecture by Martin Fowler. It will provide you with a good foundation for layering your application.

I prefer not to return datatables from my DAL methods but instead to return objects that BLL can use directly.

That's a good idea. This is where the idea of ORM comes into play. The DAL will typically know how to talk to the DB, and the DAL will also know how to convert DB-specific structures into your domain model. Domain entities go into, and back out of, the DAL. Within the DAL, domain entities are converted to DB-specific structures when persisting data. And the reverse happens: when the BLL requests data, the DAL retrieves the data and converts it to domain enties before passing it back out.

Obviously, "Hello World" doesn't require a separated, modular front-end and back-end. But any sort of Enterprise-grade project does.

Assuming some sort of spectrum between these points, at which stage should an application be (conceptually, or at a design level) multi-layered? When a database, or some external resource is introduced? When you find that the you're anticipating spaghetti code in your methods/functions?

There is no real answer to this question. It depends largely on your application's needs, and numerous other factors. I'd suggest reading some books on design patterns and enterprise application architecture. These two are invaluable:

Design Patterns: Elements of Reusable Object-Oriented Software

Patterns of Enterprise Application Architecture

Some other books that I highly recommend are:

The Pragmatic Programmer: From Journeyman to Master

Refactoring: Improving the Design of Existing Code

No matter your skill level, reading these will really open your eyes to a world of possibilities.

Philosophical question here When it comes to OOP and databases, specifically, programs where the classes are backed up with databases, what is the best way to approach this? For instance, a team class might have a collection of players. The program would just load all of the team data from the database at startup, do all the manipulation in memory, and then write the database at close. Or is it better to write each data manipulation to the database as changes occur? And if this is the better way, why load the data into memory in the first place?

The other concern is that it seems to me that databases break standard OOP in one important way. With my team class with the collection of players, using OOP, the player class would not need to have a property to hold the team name. The player would get the team name from the team class of which it is a member. Now, to save the player in the database, each player record will have to have a column for the team name (or team id, but that's the same thing).

In other words, if you needed a GetAllPlayers() method, would you make it a member method in the team class, to return from memory all of the players in the collection, or make a static method in the player class to get all of the players from the database?

Anyone got any tips on how to answer these questions?

It's been a while since I have taken a programming class. Anyone know of a good text book that goes into understanding the best approach here?

Databases break object-orientation in a much more fundamental way. (Or objects break the relational model. It depends on whether you're a middle tier OO person or a DBA.)

Relational databases are set based by definition, declarative in nature. Object-oriented languages are object-instance based. Making the two work together is difficult because of "object-relational impedance mismatch". This is why you see so many ORM solutions (e.g. TopLink, Hibernate, etc.) All of them are trying to fool object-oriented programmers into thinking that they only need deal with objects and not worry about relational databases.

However you implement it, I think persistence should be separate from model objects. I usually put relational code in an interface-based data access layer. That way model objects don't have to know whether or not they're persisted, and I isolate the CRUD operations in a single package.

As for recommended reading, I'll offer Fowler's Patterns of Enterprise Application Architecture for your consideration.

This is one thing that has been bugging me for a while about DDD. I can clearly see the benefits of the approach when dealing with non-technical business domains with complex models and lots of interaction required between technical people and non-technical domain experts.

However, what about when the 'domain' in question is technical?

For instance, situation A) take a web start-up. Imagine they are trying to accomplish something quite complicated (say a facebook clone), but almost all of the staff are technical (or at least have strong technical understanding).

What about situation B) A similar situation, but with a slightly less ambitious project, and a lone developer trying to create somthing with an elegant architecture.

I'd be really interested to hear what people have to say. What I'm really trying to get to the meat of, is where the benefits of DDD lie, what the downsides might are, and at what point one outweighs the other...

DDD is really just an elaboration of the design pattern Fowler calls Domain Model in Patterns of Enterprise Application Architecture. In that book, he compares Domain Model to other ways of organizing code, such as Transaction Script, but it is clear that he prefers Domain Model over other alternatives for all but the simplest of applications. I do, too.

DDD simply expands greatly on the original concept of a Domain Model and provides tons of guidance on how we should analyze and model our domain in a way that will be beneficial to ourselves as developers.

If the Domain in question is complex, then a Domain model (and hence DDD) is a good choice. It doesn't really matter whether the Domain is business-oriented or more technical in nature. In his book Domain-Driven Design, Eric Evans starts by describing how the DDD techniques helped him model a Printed Circuit Board application. That is surely a technical Domain, if any!

In my current work, we are using DDD to model an application that deals with Claims-based identity - another very technical Domain.

DDD is really just about dealing with complexity in sofware, and this is also the subtitle of Evans' book: "Tackling Complexity in the Heart of Software."

We have a class home work for design pattern class. In that we have to explain anyone design pattern used in any api/framework. I was thinking if I could do the same using Android apis. I know that android uses some command, observer, template method patterns and many more but it would be great if someone could point me to the starting reference document or so.

Thank you so much in advance.

Frameworks almost by definition tend to implement high-level patterns such as MVC or ORM patterns. These are not covered in the GOF text, although you will find them in other pattern books such as Martin Fowler's Patterns of Enterprise Application Architecture. Some GOF patterns are implemented at the framework or even language-level (like C# events/delegates as an example of the Observer pattern), but mostly GOF patterns are left to the individual developer to implement as needed, as the details tend to be application or domain-specific.

Android is the same way. It has a specific flavor of Model-View-Controller built in, but not too many GOF-specific patterns. You might consider the Activity lifecycle callbacks (onStart, onResume, etc.) as a kind of Observer pattern, although with only one dedicated subscriber.

Another example might be AsyncTask, which could be considered a species of the Command Pattern. I'll leave it to you to make the connection. It is homework after all.

What are the possible data access layer design-patterns for c# applications ?

Any advice will be useful. Thanks.

A lot of data access layer design-patterns are described here. 3 tier architecture with data mapping is widely spread

assume a data structure Person used for a contact database. The fields of the structure should be configurable, so that users can add user defined fields to the structure and even change existing fields. So basically there should be a configuration file like

FieldNo  FieldName          DataType           DefaultValue
 0        Name               String             ""
 1        Age                Integer            "0"

The program should then load this file, manage the dynamic data structure (dynamic not in a "change during runtime" way, but in a "user can change via configuration file" way) and allow easy and type-safe access to the data fields.

I have already implemented this, storing information about each data field in a static array and storing only the changed values in the objects.

My question: Is there any pattern describing that situation? I guess that I'm not the first one running into the problem of creating a user-adjustable class?

Thanks in advance. Tell me if the question is not clear enough.

I suggest looking at the various Object-Relational pattern in Martin Fowler's Patterns of Enterprise Application Architecture available here. This is a list of patterns it covers here.

The best fit to your problem appears to be metadata mapping here. There are other patterns, Mapper, etc.

Consider the following situation. I have 3 tables in a resource planning project(created using mysql)

  1. raw_materials (stores details about all raw materials)

  2. procurement_orders (stores details about all details about requests sent to vendors for sending us the quotations. This table references the raw_materials table.)

  3. quotations (contains details about all quotations sent by vendors to us. This table references the procurement_orders table).

I have created dbManagers for each of them using java which specialize in storing,retrieving,deleting data from respective tables.

My question is if i want to retrieve data which has to needs data from other tables, what is the best way to do it. eg:I want quotations of all raw_materials having stock below x. then according to me there are two ways

  1. i write it in dbManager for rawMaterials. The flaw with this technique is it tries to access data out of its domain directly.
  2. in dbManager of of raw_Materials create instances of other dbManagers. The flaw here is the iterations will large. As in if there are 300 raw materials, i will have to call method of the procurement_request's dbManager 300 times. If it returns multiple values we will again have to call dbMnager of quatations many no. of times(many of them will be unwanted) affecting performance.

My question is what is the best way to design it in a proper oo way without hitting the performance.

This is a rather larger question than can easily be handled quickly, but aligning java classes to tables is not necessarily a good approach, precisely because as you note, some things naturally involve multiple tables in complex relations.

I'd recommend starting by looking at Martin Fowler's book Patterns of Enterprise Application Architecture.

Patterns of Enterprise Application Architecture.

There are also some notes on the patterns in this book at his website.

Your usage most nearly resembles Table Data Gateway. Following this pattern, it would be perfectly reasonable to have methods in each of your dbManager classes that retrieves data from its associated table but involves another table as part of a where clause.

You might also want to consider Object-relational mapping as implemented for instance by Hibernate.

Does anyone know of any design patterns for interfacing with relational databases? For instance, is it better to have SQL inline in your methods, or instantiate a SQL object where you pass data in and it builds the SQL statements? Do you have a static method to return the connection string and each method just gets that string and connects to the DB, performs its action, then disconnects as needed or do you have other structures that are in charge of connecting, executing, disconnecting, etc?

In otherwords, assuming the database already exists, what is the best way for OO applications to interact with it?

Thanks for any help.

I recommend the book Patterns of Enterprise Application Architecture by Martin Fowler for a thorough review of the most common answers to these questions.

POEAA has a wealth of knowledge on the issue if you intend to roll your own.

Does the below code show an acceptable way to cache both fully built pages and database queries?

The caching of built pages is started with the __construct in the controller and then finished with the __destruct, in this example all pages are cached for a default of 15 minutes to a file.

The query caching is done with apc and they are stored in memory for the specified amount of time per query. In the actual site there would be another class for the apc cache so that it could be changed if required.

My aim was to build the most simple possible mvc, have I failed or am I on the right sort of track?


//initialiser - 

class controller {

    var $cacheUrl;

    function __construct(){

        $cacheBuiltPage = new cache();
        $this->cacheUrl = $cacheBuiltPage->startFullCache();

    function __destruct(){

        $cacheBuiltPage = new cache();

class forumcontroller extends controller{

    function buildForumThread(){

        $threadOb = new thread();
        $threadTitle = $threadOb->getTitle($data['id']);

        require 'thread.php';


class thread extends model{

    public function getTitle($threadId){

        $core = Connect::getInstance();
        $data = $core->dbh->selectQuery("SELECT title FROM table WHERE id = 1");

        return $data;


class database {

    public $dbh;
    private static $dsn  = "mysql:host=localhost;dbname=";
    private static $user = "";
    private static $pass = '';  
    private static $instance;

    private function __construct () {
        $this->dbh = new PDO(self::$dsn, self::$user, self::$pass);

    public static function getInstance(){
            $object =  __CLASS__;   
            self::$instance = new $object;
        return self::$instance;

    public function selectQuery($sql, $time = 0) {

        $key = md5('query'.$sql);

        if(($data = apc_fetch($key)) === false) {

            $stmt = $this->dbh->query($sql);
            $data = $stmt->fetchAll();

            apc_store($key, $data, $time);
        return $data;


class cache{

    var url;

    public function startFullCache(){

        $this->url = 'cache/'.md5($_SERVER['PHP_SELF'].$_SERVER['QUERY_STRING']);   

        if((@filesize($this->url) > 1) && (time() - filectime($this->url)) < (60 * 15)){


        return $this->url;

    public function endFullCache($cacheUrl){

        $output = ob_get_contents();

        $output = sanitize_output($output);

        file_put_contents($cacheUrl, $output);

        echo $output;



<title><?=$threadTitle[0]?> Thread - Website</title>

    <h1><?=$threadTitle[0]?> Thread</h1>


"Outsource" the caching

First of all, you have to understand that caching of GET request is usually done all over the internet. Especially if your user is connecting via some kind of proxy.

And then there is also ability to set long expire time, so that user's browser does the caching of the HTML page and/or the media files.

For starting to look into this, you should read these two articles.

What is your goal?

Before you begin attempting to add cache, make sure that you actually need it. Do some benchmarking and look into what are your bottlenecks. Optimization for sake of optimizing is pointless and often harmful.

If you KNOW (and have data to back it up .. it's not about "feeling") that your application is making too many SQL queries, instead of jumping to query caching, you should begin by examining, what are those queries for.

For example:
If you see, that you are performing slow query each page-view just to generate a tag cloud, you instead should store the already completed tag cloud (as HTML fragment) and update it only, when something has changed.

Also, "add cache" should never be your first step, when trying to improve performance. If your queries are slow, use EXPLAIN to see if they are using indexes properly. Make sure that you are not querying same data multiple times. And also see, if queries actually make sense.

This is not MVC

I am not sure, where did you learn to write this way, but you seem to be missing the whole point of MVC:

  • "view" is not a template
  • "model" is not a database abstraction
  • "controller" is not application logic

You also seem to be missing the meaning for the word "layer". It is NOT a synonym for "class". Layers are groups of reusable components that are reusable in similar circumstances [1].

You might benefit from reading this and this post. They should help you understand the basic of this architectural pattern.

Where to cache in MVC architecture?

There are basically two points at which you can do the caching, when working with MVC (or MVC-inspired) architecture: views and persistence logic.

Caching for views would mostly entail reuse of once rendered templates (each view in MVC would be juggling multiple templates and associated UI logic). See the example with tag cloud earlier.

The caching in persistence logic would depend on your implementation.

  • You can cache the data, that is supposed to be passed to the domain objects, withing services:

    Note: in real application the new instances would not be here. Instead you would be using some factories

    $user = new User;
    $user->setId( 42 );
    $cache = new Cache;
    if ( !$cache->fetch( $user ))
        $mapper = new UserMappper;
        $mapper->fetch( $user );
    $user->setStatus( User::STATUS_BANNED );
    $cache->store( $user );
    $mapper->store( $user );
    // User instance has been populated with data
  • The other point for cache would be Repositories and/or Identity maps, if you expand the persistence layer beyond use of simple mapper. That would be too hard explain in with a simple code example. Instead you should read Patterns of Enterprise Application Architecture book.

.. some other bad practices in your code:

  • Please stop using singletons for establishing DB connection. It makes impossible to write unit tests and causes tight coupling to specific name of a class. I would recommend to instead use this approach and inject the DB connection in classes, that require it.

  • Also, if your query has no parameters, there is no point in preparing it. Prepared statement are for passing data to SQL .. but none of your example has any parameters.

    This issue arises mostly because of your magical Database class. Instead you should separate the persistence logic in multiple data mappers. This way you would not be face with self-inflicted problem of having single method for all queries.

  • The var keyword is an artifact of PHP4. Nowadays we use public, private and protected.

  • You are hard coding the connection details in your code. It is basically a violation of OCP (the dumbed-down version: here).

I am in the process of integrating a number of legacy systems. They each have different databases; and I will need to write data access code for most of them.

The database schemas cannot be changed (I might be able to apply some indexes and such, but tables and their columns must retain the structure). Some of the databases has an OK design, with appropiate relationsships and primary / foreign keys, and some of the other databases lacks that very much.

Which ORM would you choose for this task ? I would like to use the same ORM accross the project; and my requirements are:

  • Ability to rename tables or columns in code; but retain the old name in the database.
  • Reasonable code generation
  • Efficient LINQ support (LINQ queries against the data model should be translated to efficient SQL).
  • Generated data classes should preferably be POCO's.
  • Preferably support for different database engines.

I currently have the most experience with LINQ-To-SQL; but I have a feeling it might be the wrong choice for this project. I am willing to invest some time in learning a new framework.

At a guess, I think an ORM might cause you more trouble than it saves. If you have several different legacy databases where some of them are poorly designed, you might find it easier to build the data access layer at a lower level than an ORM. Fowler's Patterns of Enterprise Application Architecture does quite a good job of cataloguing various approaches to structuring data access layers.

Some of the data access layer might be amenable to a code generation solution; however the presence of a variety of schemas (some messy as you say) suggests that a one-size-fits-all approach may not work, or may involve disproportionate effort to make it play nicely with all of the legacy databases.

I am not a pro in MySQL, but want to do something like Object Layer above relational MySQL tables.

I want to have very many "structures" with a fields of type "bigint", "longtext", "datetime", "double" stored in just 7 tables.

entity_types (et_id, et_name) - list of "structures";

entity_types_fields (etf_id, parent_et_id, ....., etf_ident, etf_type) - list of structure properties stored in one table for ALL structures; etf_type contains int value (0,1,2,3) which referenced to one of 4 tables described below.

entities (e_id, et_id) - list of all available entities (id and type id of entity)

and 4 data tables (containing all data for entities) -

entities_props_bigint (parent_e_id, parent_etf_id, ep_data) - for BIGINT data properties entities_props_longtext (parent_e_id, parent_etf_id, ep_data) - for LONGTEXT data properties entities_props_datetime (parent_e_id, parent_etf_id, ep_data) - for DATETIME data properties entities_props_double (parent_e_id, parent_etf_id, ep_data) - for DOUBLE data properties

What the best way to do selection from such data layer ?

Let I have list of e_id (id of entities), each entity can have any type. I want to get predefined list of properties. If some of entities don't have such property, I want to have it equal to NULL.

Do you have some info about how to do it ? May be you have some links or have already deal with such things.


You're reinventing the wheel by implementing a whole metadata system on top of a relational database. Many developers have tried to do what you're doing and then use SQL to query it, as if it is relational data. But implementing a system of non-relational data and metadata in SQL is harder than you expect.

I've changed the relational tag of your question to eav, because your design is a variation of the Entity-Attribute-Value design. There's a limit of five tags in Stack Overflow. But you should be aware that your design is not relational.

A relational design necessarily has a fixed set of attributes for all instances of an entity. The right way to represent this in a relational database is with columns of a table. This allows you to give a name and a data type to each attribute, and to ensure that the same set of names and their data types apply to every row of the table.

What the best way to do selection from such data layer ?

The only scalable way to query your design is to fetch the attribute data and metadata as rows, and reconstruct your object in application code.

SELECT e.e_id, f.etf_ident, f.etf_type, 
    p0.ep_data AS data0, 
    p1.ep_data AS data1, 
    p2.ep_data AS data2,
    p3.ep_data AS data3
FROM entities AS e
INNER JOIN entity_type_fields AS f ON e.et_id = f.parent_et_id
LEFT OUTER JOIN entities_props_bigint   AS p0 ON (p0.parent_e_id,p0.parent_etf_id) = (e.e_id,f.etf_id) 
LEFT OUTER JOIN entities_props_longtext AS p1 ON (p1.parent_e_id,p1.parent_etf_id) = (e.e_id,f.etf_id) 
LEFT OUTER JOIN entities_props_datetime AS p2 ON (p2.parent_e_id,p2.parent_etf_id) = (e.e_id,f.etf_id) 
LEFT OUTER JOIN entities_props_double   AS p3 ON (p3.parent_e_id,p3.parent_etf_id) = (e.e_id,f.etf_id) 

In the query above, each entity field should match at most one property, and the other data columns will be null. If all four data columns are null, then the entity field is missing.

Re your comment, okay now I understand better what you are trying to do. You have a collection of entity instances in a tree, but each instance may be a different type.

Here's how I would design it:

  • Store any attributes that all your entity subtypes have in common in a sort of super-type table.

    entities(e_id,entity_type,name,date_created,creator,sku, etc.)

  • Store any attributes specific to an entity sub-type in their own table, as in Martin Fowler's Class Table Inheritance design.

    entity_books(e_id,isbn,pages,publisher,volumes, etc.)

    entity_videos(e_id,format,region,discs, etc.)

    entity_socks(e_id,fabric,size,color, etc.)

  • Use the Closure Table design to model the hierarchy of objects.

    entity_paths(ancestor_e_id, descendant_e_id, path_length)

For more information on Class Table Inheritance and Closure Table, see my presentations Practical Object-Oriented Models in SQL and Models for Hierarchical Data in SQL, or my book SQL Antipatterns: Avoiding the Pitfalls of Database Programming, or Martin Fowler's book Patterns of Enterprise Application Architecture.

I am putting some heavy though into re-writing the data access layer in my software(If you could even call it that). This was really my first project that uses, and things were done in an improper manner.

In my project all of the data that is being pulled is being stored in an arraylist. some of the data is converted from the arraylist into an typed object, before being put backinto an arraylist.

Also, there is no central set of queries in the application. This means that some queries are copy and pasted, which I want to eliminate as well.This application has some custom objects that are very standard to the application, and some queries that are very standard to those objects.

I am really just not sure if I should create a layer between my objects and the class that reads and writes to the database. This layer would take the data that comes from the database, type it as the proper object, and if there is a case of multiple objects being returned, return a list of those object. Is this a good approach?

Also, if this is a good way of doing things, how should I return the data from the database? I am currently using, and filling an array list. I am sure that this is not the best method to use here, i am just not real clear on how to improve this.

The Reason for all of this, is I want to centralize all of the database operations into a few classes, rather than have them spread out amongst all of the classes in the project

"I am really just not sure if I should create a layer between my objects and the class that reads and writes to the database. This layer would take the data that comes from the database, type it as the proper object, and if there is a case of multiple objects being returned, return a list of those object. Is this a good approach?"

I'm a Java developer, but I believe that the language-agnostic answer is "yes".

Have a look at Martin Fowler's "Patterns Of Enterprise Application Architecture". I believe that technologies like LINQ were born for this.

I had to clean up code for an online college application. There's nothing particularly wrong with it, but it was complicated. Different degree programs had different prequisites, fees, required documentation, and questions. On top of that, students coming from the military get different fees, and previous students pay no fees and skip steps.

Obviously all this logic can get pretty complex - and cause bugs. I'm wondering if there's a design pattern or coding method that would help with organizing the logic. I'm using PHP, not that it matters.

The strategy pattern seems to have the most potential, but it seems to me I'd need strategies on top of strategies for this.

I imagine the field of "Business Logic" might cover this at least partially, but searches haven't turned up indications of any elegant coding methods to use.

I think a combination of patterns would be helpful. Fowler's Domain Model pattern aims to tame complex domain logic. Using a Layered architectural pattern is another option, as described in POSA1. Strategy pattern also seems to be a good idea for defining a family of related algorithms.

I have an MVC app I'm writing. There will be the need for multiple instances of the same page to be open, each accessing different records from a database, these record objects will also need to be passed through a flow of pages, before finally being updated.

What's the best, and most correct, way of acheiving this - should/can I create a custom model binder that links to an object via it's unique ID and then create each record-object in the session, updating them as I go through each one's page flow and then finally calling the update method? Or is there a better way of dealing with this?



Technically, that would be possible, but I don't think it is advisable. When you look at the signature of IModelBinder, you will have to jump through some hoops related to the ControllerContext if you want to be able to access the rest of your application's context (such as how to dehydrate objects based on IDs).

It's possible, but so clunky that you should consider whether it's the right approach. In my opinion, a ModelBinder's responsibility is to map HTTP request data to strongly typed objects. Nothing more and nothing less - it is strictly a mapper, and trying to make it do more would be breaking the Single Responsibility Principle.

It sounds to me like you need an Application Controller - basically, a class that orchestrates the Views and the state of the underlying Model. You can read more about the Application Controller design pattern in Patterns of Enterprise Application Architecture.

Since a web application is inherently stateless, you will need a place to store the intermediate state of the application. Whether you use sessions or a custom durable store to do that depends on the application's requirements and the general complexity of the intermediate data.

I have used to use PHP and MySQL a lot "back in the day" to create all kinds of websites including text-based games.

Back when I was creating these project I was using such code as:

$query = 'SELECT user FROM users WHERE user_id = 1';
$result = mysql_query($query);

To get results from the database. I realise that this is a very bad way to be doing it, my questions is what is the best way to now do SELECT, UPDATE, DELETE etc. As these will be used all over the website should I be making functions in one file and so on. I would like to know the "best/safest" way to do about doing this. I understand having SQL statements on one line is bad as they are open to SQL injections, I would like to know what this means exactly and how to get around this problem safely.

Its mainly handling the database that I seem to not understand. As I have not been paying attention to PHP for a few years now I see many things have moved on from when I had created my projects.

I have looked around the net and have found W3Schools to be a useful resource but I would like to hear it from people that are using this everyday to find out how I should be doing things.

Overall, how do I go about safely connecting a database and how can I grab data form the database safely for the whole website to use.

This includes:

  • Connecting a database
  • Getting database from the database
  • Echo the data from the database onto a page

And anything else that you can think of to help me understand how to structure a "safe" website.

Thanks to anyone that replies to this/these questions, I will be very active in comments for this asking more questions about things I do not full understand.

Side Note: this website will be created using HTML, JavaScript, PHP and using a MYSQL database.

It's all start with Separation of concerns and nowadays the most popular architecture for web applications is Model-View-Controller (you don't need to invent one, you may use some of the existing PHP frameworks, each of them is bundled with some kind of ORM).

Since you are asking about isolating the database code, the models is the first thing you should learn from the MVC paradigm. All operations on the data, including any business logic and calculations, all DB operations, go to the model classes. There are different way you may structure them. One popular pattern is the Active Record - literally a class per table. I'm not a big fan of this - you may create classes after your logical entities (user, game, etc), and they may operate on multiple tables. But those classes may be build upon Active Record anyway.

If you are working with existing code, you can start with isolating the queries in objects, so all code that work with the database is in one place - then you can start restructure objects to follow the chosen architecture : User objects works with the users table, and so on... After you separated the DB code in objects, you can easily switch to PDO or other db-implementations and protect from SQL injections.

In the end I'd like to recommend few books: Refactoring - the best book about how to turn legacy code in beautiful OO solutions

Patterns of enterprise application architecture - hard to read but has a lot of useful info

Implementation Patterns - unlike books on Design Patterns, this is focused on the small decisions, literally on each line of code

I'm asking all of you who aren't using a library for this, but are constructing your own objects for managing data flowing to and from your database tables. Do I have a recordset object? one object per row of data? Both? Neither? Any suggestions or experiences welcome. Please don't tell me to use an ORM or other such toolkit. It's overkill for my project and besides, that's not the question now, is it?

i'd strongly suggest picking up martin fowler's patterns of enterprise application architecture, it describes a number of database patterns that would be helpful to know, and give you an idea of the evolution of patterns to full on ORM libraries.

specific patterns you may be interested in:

these basic patterns will give you an idea of how to structure your objects, and the more advanced patterns (like active record/data mapper) you'll see how those relate to problem domains beyond where your needs are at the moment.

I'm learning DDD and trying to implement Repository using Google Datastore.

I find recreating DDD entities from datastore quite tricky. I've read there are frameworks to map my DDD entities to datastore entities, but I would like to learn low-level API first.

I though, the repository could set the state of an entity using setters, but this is often considered anti-pattern in DDD.

An alternative would be to use builder pattern, where builder instance is passed to the constructor of an entity. However, this introduce to the entity a functionality (restoring entity state) that is out of its responsibility.

What are good patterns to solve problem?

The whole Chapter 6 of Eric Evans book is devoted to the problems you are describing.

First of all, Factory in DDD doesn't have to be a standalone service -

Evans DDD, p. 139:

There are many ways to design FACTORIES. Several special-purpose creation patterns - FACTORY METHOD, ABSTRACT FACTORY, and BUILDER - were thoroughly treated in Gamma et. al 1995. <...> The point here is not to delve deeply into designing factories, but rather to show the place of factories as important components of a domain design.

Each creation method in Evans FACTORY enforces all invariants of the created object, however, object reconstitution is a special case

Evans DDD, p. 145:

A FACTORY reconstituting an object will handle violation of an invariant differently. During creation of a new object, a FACTORY should simply balk when invariant isn't met, but a more flexible response may be necessary in reconstitution.

This is important, because it leads us to creating separate FACTORIES for creation and reconstitution. (in the diagram on page 155 TradeRepository uses a specialized SQL TradeOrderFactory, not a general general purpose TradeOrderFactory )

So you need to implement a separate logic for reconstitution, and there are several ways to do it (You can find the full theory in Martin J Fowler Patterns Of Enterprise Application Architecture, on page 169 there's a subheading Mapping Data to Domain Fields, but not all of methods described look suitable(for example making the object fields package-private in java is seems to be too intrusive) so I'd prefer only one of the following two options

  • You can create a separate FACTORY and document it so that developers should only use it only for persistence or testing.
  • You can set the private field values with reflection, as for example Hibernate does.

Regarding the anemic domain model with setters/and getters, the upcoming Vaughn Vernon book criticizes this approach a lot so I dare say it is an antipattern in DDD.

I'm toying with an application that is, roughly speaking, a sort of modeler application for the building industry. In the future I'd like it to be possible for the user to use both SI units and imperial. From what I understand, it's customary in the US building industry to use fractions of inches when specifying measurements, eg 3 1/2" - whereas in SI we'd write 3.5, not 3 1/2. I'm looking for a way to work with these different systems in my software - storing them, doing calculations on them etc, not only parsing what a users enters. It should be able to show the user a measurement in the way he entered it, yet being able to calculate with other measurements - for example add 3 cm to 1 1/2 inch. So if a user draws a length of wall of 5 feet and another one of 3 meters, the total measurement should be shown in the default unit system the user selected.

I'm undecided yet on how much flexibility I should add for entering data for the user; e.g. if he enters 1 foot 14 inches, should it should 2 feet 2 inches the next time the measurement is shown? However before I decide things like that, I'm looking for a way to store measurements in an exact form, which is what my question is about.

I'm using C++ and I've looked at Boost.Units, but that doesn't seem to offer a way to deal with fractions.

The simple option is to convert everything to millimeters, but rounding errors would make it impossible to go back to the exact measurement a user entered (if he entered it in imperial measurements). So I'll need something more complex.

For now I'm using a class that is tentatively named 'Distance' and looks conceptually like this:

class Distance
    Distance(double value);
    // operators +, -, *, /
    Distance operator+(const Distance& that);

    std::string StringForm(); // Returns a textual form of the value

    Distance operator=(double value);

    <question: what should go here?>

This clearly shows where my problems are. The most obvious thing to do would be to have an enum that says whether this Distance is storing SI or imperial units, and have fields (doubles, presumably) that store the meters, centimeters and millimeters if it's in SI units and feet and inches if it's imperial. However this will make the implementation of the class littered with if(SI) else ..., and is very wasteful in memory. Plus I'd have to store a numerator and denominator for the feet and inches to be able to exactly store 1/3", for example.

So I'm looking for general design advice on how I should solve these problems, given my design requirements. Of course if there's a C++ library out there that already does these things, or a library in another language I could look at to copy concepts from, that would be great.

Take a look at Martin Fowler's Money pattern from Patterns of Enterprise Application Architecture - it is directly applicable to this situation. Recommended reading. Fowler has also posted a short writeup on his site of the Quantity pattern, a more generic version of Money.

I'm trying to decide if MSMQ is the right tool for communication between our application and a third party web service we are currently communicating with directly. We're looking to uncouple this such that if the service goes down, life could still go on as normal.

I can't find anything outside the usual MS fluff about it being the greatest thing and solving all your problems etc etc. It would be really useful if I could find some information that was somewhere between marketing fluff and API - like an architecture diagram of the components and how they integrate with each other, and more importantly how I integrate with them.

It's probably that I'm just looking for the information in the wrong places, so if someone could point me in the right direction, I'd appreciate it.

MSMQ is a implementation of a message queue as are websphere mq and a bunch of other systems. When looking into the concepts and high level architecture I would suggest reading up on message queue's and how they are applied in disconnected scenario's. I can highly recommend Patterns of Enterprise Application Architecture. For specific examples on msmq check out Pro MSMQ: Microsoft Message Queue Programming it doesn't contain allot of special information but it does group it allot better then most resources available on the internet. This Hello World with MSMQ article would give you a nice overview of what it entails and it's easily executed on a development system.

I think I am pretty good with programming C# syntax. What I am looking for now is some resources, books(preferable), websites, blogs, that deal with the best way to design object oriented Desktop Applications and Web applications, especially when it comes to data and databases.


Martin Fowler's Enterprise-Application-Architecture is a great book for common pattern's you'll see in a lot of client server applications.

More of a book on thinking about object oriented problems is Eric Evan's Domain-Driven Design: Tackling Complexity in the Heart of Software

You are asking to drink from a firehose. Let me encourage you to write some small programs before you tackle big ones. However, here are a few books about design and a paper which argues that a lot of design can't be learned from books:

  • On System Design is a good short paper that articulates what a lot of experienced programmers think about the art of design.

  • Programming Pearls by Jon Bentley presents some lovely examples of design in the small. It's a fun read and includes many classic stories.

  • The Unix Programming Environment by Kernighan and Pike presents one of the great software-design philosophies of the 20th century. Still required reading after almost 25 years.

  • Software Tools in Pascal is narrower and deeper but will tell you a lot about the specifics of building software tools and the design philosophy.

  • Abstraction and Specification in Program Development by Barbara Liskov and John Guttag will teach you how to design individual modules so they can fit with other modules to form great libraries. It is out of print but your local University library may have it.

  • C Interfaces and Implementations presents a very well designed library that gives C programmers the abstractions found in much higher-level languages.

  • Finally, Test-Driven Development will teach you how to articulate and develop a design through the stuff that matters: what your software actually does.

I learned a lot from Composite/Structured Design by Glenford Myers, but it bears a little less directly on the topics you asked about. It talks primarily about good and bad ways modules can interdepend.

For a book on how to develop software I would recommend The Pragmatic Programmer. For design you may want to look at Interface Oriented Design. Code Complete is an "A to Z" reference on developing software. You might also want to consider the O'Reilly Head First books, especially Head First Object-Oriented Analysis and Design, as something a little easier to start with.

EDIT I don't know how I forgot about Bob Martin, but you could also read any of the books that Object Mentor has on any of it's lists. Here is their section on Software Design. In particular I'd recommend Agile Software Development: Principles, Patterns, and Practices (Amazon, but it's also the second book on the Object Mentor list).

I haven't been thrilled with any of the recent books, so much so that I'm seriously thinking about writing a new one. The "Head First" books generally have read to me ike one step above the "For Dummies" books (to be fair, I haven't read that one.)

I'm actually fond of Peter Coad's Java Design; you can get one cheaply used, it's no longer in print. Obviously, it's Java heavy, but the design part is good, and pretty lightweight.

Ivar Jacobson's Object Oriented Software Engineering is also very good (it introduced the idea of "use cases", among other things) and does appear to still be in print, but there are zillions of used copies around.

I've developed on the Yii Framework for a while now (4 months), and so far I have encountered some issues with MVC that I want to share with experienced developers out there. I'll present these issues by listing their levels of complexity.

[Level 1] CR(create update) form. First off, we have a lot of forms. Each form itself is a model, so each has some validation rules, some attributes, and some operations to perform on the attributes. In a lot of cases, each of these forms does both updating and creating records in the db using a single active record object.
-> So at this level of complexity, a form has to

  • when opened,

    • be able to display the db-friendly data from the db in a human-friendly way

    • be able to display all the form fields with the attributes of the active record object. Adding, removing, altering columns from the db table has to affect the display of the form.

  • when saves, be able to format the human-friendly data to db-friendly data before getting the data

  • when validates, be able to perform basic validations enforced by the active record object, it also has to perform other validations to fulfill some business rules.

  • when validating fails, be able to roll back changes made to the attribute as well as changes made to the db, and present the user with their originally entered data.

[Level 2] Extended CR form. A form that can perform creation/update of records from different tables at once. Not just that, whether a form would create/update of one of its records can sometimes depend on other conditions (more business rules), so a form can sometimes update records at table A,B but not D, and sometimes update records at A,D but not B -> So at this level of complexity, we see a form has to:

  • be able to satisfy [Level 1]

  • be able to conditionally create/update of certain records, conditionally create/update of certain columns of certain records.

[Level 3] The Tree of Models. The role of a form in an application is, in many ways, a port that let user's interact with your application. To satisfy requests, this port will interact with many other objects which, in turn, interact with many more objects. Some of these objects can be seen as models. Active Record is a model, but a Mailer can also be a model, so is a RobotArm. These models use one another to satisfy a user's request. Each model can perform their own operation and the whole tree has to be able to roll back any changes made in the case of error/failure.

Has anyone out there come across or been able to solve these problems?

I've come up with many stuffs like encapsulating model attributes in ModelAttribute objects to tackle their existence throughout tiers of client, server, and db.

I've also thought we should give the tree of models an Observer to observe and notify the observed models to rollback changes when errors occur. But what if multiple observers can exist, what if a node use its parent's observer but give its children another observers.

Engineers, developers, Rails, Yii, Zend, ASP, JavaEE, any MVC guys, please join this discussion for the sake of science.

--Update to teresko's response:---
@teresko I actually intended to incorporate the services into the execution inside a unit of work and have the Unit of work not worry about new/updated/deleted. Each object inside the unit of work will be responsible for its state and be required to implement their own commit() and rollback(). Once an error occur, the unit of work will rollback all changes from the newest registered object to the oldest registered object, since we're not only dealing with database, we can have mailers, publishers, etc. If otherwise, the tree executes successfully, we call commit() from the oldest registered object to the newest registered object. This way the mailer can save the mail and send it on commit.

Using data mapper is a great idea, but We still have to make sure columns in the db matches data mapper and domain object. Moreover, an extended CR form or a model that has its attributes depending on other models has to match their attributes in terms of validation and datatype. So maybe an attribute can be an object and shipped from model to model? An attribute can also tell if it's been modified, what validation should be performed on it, and how it can be human-friendly, application-friendly, and db-friendly. Any update to the db schema will affect this attribute, and, thereby throwing exceptions that requires developers to make changes to the system to satisfy this change.

The cause

The root of your problem is misuse of active record pattern. AR is meant for simple domain entities with only basic CRUD operations. When you start adding large amount of validation logic and relations between multiple tables, the pattern starts to break apart.

Active record, at its best, is a minor SRP violation, for the sake of simplicity. When you start piling on responsibilities, you start to incur severe penalties.


Level 1:

The best option is the separate the business and storage logic. Most often it is done by using domain object and data mappers:

  • Domain objects (in other materials also known as business object or domain model objects) deal with validation and specific business rules and are completely unaware of, how (or even "if") data in them was stored and retrieved. They also let you have object that are not directly bound to a storage structures (like DB tables).

    For example: you might have a LiveReport domain object, which represents current sales data. But it might have no specific table in DB. Instead it can be serviced by several mappers, that pool data from Memcache, SQL database and some external SOAP. And the LiveReport instance's logic is completely unrelated to storage.

  • Data mappers know where to put the information from domain objects, but they do not any validation or data integrity checks. Thought they can be able to handle exceptions that cone from low level storage abstractions, like violation of UNIQUE constraint.

    Data mappers can also perform transaction, but, if a single transaction needs to be performed for multiple domain object, you should be looking to add Unit of Work (more about it lower).

    In more advanced/complicated cases data mappers can interact and utilize DAOs and query builders. But this more for situation, when you aim to create an ORM-like functionality.

    Each domain object can have multiple mappers, but each mapper should work only with specific class of domain objects (or a subclass of one, if your code adheres to LSP). You also should recognize that domain object and a collection of domain object are two separate things and should have separate mappers.

    Also, each domain object can contain other domain objects, just like each data mapper can contain other mappers. But in case of mappers it is much more a matter of preference (I dislike it vehemently).

Another improvement, that could alleviate your current mess, would be to prevent application logic from leaking in the presentation layer (most often - controller). Instead you would largely benefit from using services, that contain the interaction between mappers and domain objects, thus creating a public-ish API for your model layer.

Basically, services you encapsulate complete segments of your model, that can (in real world - with minor effort and adjustments) be reused in different applications. For example: Recognition, Mailer or DocumentLibrary would all services.

Also, I think I should not, that not all services have to contain domain object and mappers. A quite good example would be the previously mentioned Mailer, which could be used either directly by controller, or (what's more likely) by another service.

Level 2:

If you stop using the active record pattern, this become quite simple problem: you need to make sure, that you save only data from those domain objects, which have actually changed since last save.

As I see it, there are two way to approach this:

  1. Quick'n'Dirty

    If something changed, just update it all ...

    The way, that I prefer is to introduce a checksum variable in the domain object, which holds a hash from all the domain object's variables (of course, with the exception of checksum it self).

    Each time the mapper is asked to save a domain object, it calls a method isDirty() on this domain object, which checks, if data has changed. Then mapper can act accordingly. This also, with some adjustments, can be used for object graphs (if they are not to extensive, in which case you might need to refactor anyway).

    Also, if your domain object actually gets mapped to several tables (or even different forms of storage), it might be reasonable to have several checksums, for each set of variables. Since mapper are already written for specific classes of domain object, it would not strengthen the existing coupling.

    For PHP you will find some code examples in this ansewer.

    Note: if your implementation is using DAOs to isolate domain objects from data mappers, then the logic of checksum based verification, would be moved to the DAO.

  2. Unit of Work

    This is the "industry standard" for your problem and there is a whole chapter (11th) dealing with it in PoEAA book.

    The basic idea is this, you create an instance, that acts like controller (in classical, not in MVC sense of the word) between you domain objects and data mappers.

    Each time you alter or remove a domain object, you inform the Unit of Work about it. Each time you load data in a domain object, you ask Unit of Work to perform that task.

    There are two ways to tell Unit of Work about the changes:

    • caller registration: object that performs the change also informs the Unit of Work
    • object registration: the changed object (usually from setter) informs the Unit of Work, that it was altered

    When all the interaction with domain object has been completed, you call commit() method on the Unit of Work. It then finds the necessary mappers and store stores all the altered domain objects.

Level 3:

At this stage of complexity the only viable implementation is to use Unit of Work. It also would be responsible for initiating and committing the SQL transactions (if you are using SQL database), with the appropriate rollback clauses.


Read the "Patterns of Enterprise Application Architecture" book. It's what you desperately need. It also would correct the misconception about MVC and MVC-inspired design patters, that you have acquired by using Rails-like frameworks.

The new place I started at is just starting to develop a completely new product from scratch. They are going transaction script in application services, completely dumb entities, and a hand rolled DAL with stored procedures (the argument is that nhibernate doesn't optimize sql well, loads too much stuff, doesn't scale well to huge projects etc etc etc). the app is supposed to be HUGE project just in it's infancy.

I'm coming from a position where I was doing domain model with all business logic encapsulated in that and the app services only handling infrastructure + loading up the model with nhibernate and scripting it.

I really believe going with the 2nd approach is much better. I was planning on doing a presentation on why. I have plenty of books/articles/personal opinions that I can back this up with...but being more of a "junior" there it might not mean much (I was also the single dev at my last place).

What I'm looking for is some experience/tips/examples of failed projects from more senior people why going transaction script/hand rolled DAL is not the right idea.

In addition to what Paul T Davies and Magnus Backeus have said. I think that at the end of the day it would be a people and cultural issue. If people are open minded and willing to learn it will be relatively easy to convince them. If they consider you a 'junior' (which is a bad sign because the only thing that matters is what you say not how old/experienced you are) you can appeal to a 'higher authority':

Stored procedures are dead and you are not the only one who thinks so:

It is startling to us that we continue to find new systems in 2011 that implement significant business logic in stored procedures. Programming languages commonly used to implement stored procedures lack expressiveness, are difficult to test, and discourage clean modular design. You should only consider stored procedures executing within the database engine in exceptional circumstances, where there is a proven performance issue.

There is no point in convincing people that are not willing to improve and learn. Even if you manage to win one argument and squeeze in NHibernate, for example, they may end up writing the same tightly coupled, untestable, data-or-linq-oriented code as they did before. DDD is hard and it will require changing a lot of assumptions, hurt egos etc. Depending on the size of the company it may be a constant battle that is not worth starting.

Driving Technical Change is the book that might help you to deal with these issues. It includes several behavior stereotypes that you may encounter:

  • The Uninformed
  • The Herd
  • The Cynic
  • The Burned
  • The Time Crunched
  • The Boss
  • The Irrational

Good luck!

The question is from the from the patterns of enterprise application architecture by Fowler.

My effort to enhance formula = d x r + c

  • d number domain definitions(classes)
  • r replication of definitions
  • c complexity constant

But having a hard time about justifying it for the table module pattern growing exponentially as there is not much replication of definitions at that part.

Why does table module effort to enhance grow exponentially ?

enter image description here


Well, it's favourite diagram of Dino Esposito :o)

Mostly it's based on developer's experience and feelings. As for me, Domain Model is applicable for not many systems, for most of them less complicated patterns should be used. May be, it's you case. Well-designd table module application can have "liner" complexity for many and many years and this is ok. But if you feel, that you spend much time on doing the same job for different parts/classes/modules of your application, if you feel, you can't control it, if you have distributed team and 10-20 developers, you can think about separation of concerns, bounded context and domain model. So, this diagram is mostly marketing step to "sell" you DDD. I like DDD, but it really takes a lot of time at the beginning and there is a chance, that you never reach time, when DDD will be easier than any non DDD-way.

So, answering your question - no reason, just to tell that sometimes DDD is better.

We're using the DTO pattern to marshal our domain objects from the service layer into our repository, and then down to the database via NHibernate.

I've run into an issue whereby I pull a DTO out of the repository (e.g. CustomerDTO) and then convert it into the domain object (Customer) in my service layer. I then try and save a new object back (e.g. SalesOrder) which contains the same Customer object. This is in turn converted to a SalesOrderDTO (and CustomerDTO) for pushing into the repository.

NHibernate does not like this- it complains that the CustomerDTO is a duplicate record. I'm assuming that this is because it pulled out the first CustomerDTO in the same session and because the returning has been converted back and forth it cannot recognise this as the same object.

Am I stuck here or is there a way around this?



As others have noted, implementing Equals and GetHashCode is a step in the right direction. Also look into NHibernate's support for the "attach" OR/M idiom.

You also have the nosetter.camelcase option at your disposal:

Furthermore, I'd like to encourage you not to be dissuaded by the lack of information out there online. It doesn't mean you're crazy, or doing things wrong. It just means you're working in an edge case. Unfortunately the biggest consumers of libraries like NHibernate are smallish in-house and/or web apps, where there exists the freedom to lean all your persistence needs against a single database. In reality, there are many exceptions to this rule.

For example, I'm currently working on a commercial desktop app where one of my domain objects has its data spread between a SQL CE database and image files on disk. Unfortunately NHibernate can only help me with the SQL CE persistence. I'm forced to use a sort of "Double Mapping" (see Martin Fowler's "Patterns of Enterprise Application Architecture") map my domain model through a repository layer that knows what data goes to NHibernate and what to disk.

It happens. It's a real need. Sometimes an apparent lack in a tool indicates you're taking a bad approach. But sometimes the truth is that you just truly are in an edge case, and need to build out some of these patterns for yourself to get it done.

What is the simplest way to use database persistence in Java? I know, many frameworks exists around the Internet, but it could be fun to learn how to develop a persistence layer by myself and its design patterns. Where to start? Books, websites, how-tos, code-examples, etc.

If you are looking for a learning practice then try to get a copy of Craig Larman's Applying UML and Patterns.

alt text

There Larman presents a chapter on lightweight database persistence mapper design. Unlike Hibernate, which is based on an unobtrusive persistence model, he presents an obtrusive framework in which domain objects has to be extended from a PersistentObject. We also have to write mapper classes for each persistent domain class. Its some sort of ActiveRecord pattern without any codegeneration concept.

I found this book to be particularly useful. This is a good one too.

Having created one myself I agree - it is a lot of fun, and a lot of work too. It all depends on your objectives.

This book (Patterns of Enterprise Application Architecture) seems very good at first sight. I have look into it, and design patterns for developing a persistence engine are very comprehensive. It tells why, when and how to use them.

Are there sample ASP.NET projects around using the patterns discussed in the book by Martin Fowler (Patterns of Enterprise Application Architecture)?

I have downloaded the Northwind starters kit and Dinner Now, which are very good. Are there others that use things like Unit of Work, Repository, ...

thx, Lieven Cardoen as C# and VB.NET GoF pattern examples. They also have a full ASP.NET web application example detailing the use of the patterns, although I don't think that is a free download.

I am about to embark on a rewrite of a VB6 application in .NET 3.5sp1. The VB6 app is pretty well written and the data layer is completely based on stored procedures. I'd like to go with something automated like Linq2SQL/Entity Framework/NHibernate/SubSonic. Admittedly, I haven't used any of these tools in anything other than throwaway projects.

The potential problem I fear I might have with all these choices is speed. For instance, right now to retrieve a single row (or the entire list), I use the following sproc:

ALTER PROCEDURE [dbo].[lst_Customers]
 @intID     INT = NULL
,@chvName   VARCHAR(100) = NULL

SELECT   Customer_id, Name
FROM dbo.Customer
WHERE (@intID IS NULL OR @intID = Customer_id)
 AND (@chvName IS NULL OR Name like ('%' + @chvName + '%'))

To retrieve a single row in Linq2SQL/Entity Framework/NHibernate/SubSonic, would these solutions have to bring the entire list down to the client and find the row that I need?

So, what's the consensus for the data access strategy for an application with a large data domain?

I'm going to play devil's advocate and recommend you at least consider sticking with the stored procedures. These represent a chunk of code that you do not have to re-write and debug. This article from our Very Own [tm] Joel Spolsky gives a coherent argument for avoiding complete re-writes.

Given a 'greenfield' project you can use what you want, and an O/R mapper might well be a good choice. However, you've already stated that the VB6 app is well written. If the sprocs are well written, then you get some of your app for free and it comes already debugged, plus you get to recycle the database schema and avoid most of the pain from data migration.

Fowler's Patterns of Enterprise Application Architecture should give you some good pointers for designing a data access layer that will play nicely with the stored procedures without causing maintenance issues.

This is done quite commonly on Oracle/Java apps. Many legacy Oracle apps have large bodies of stored procedure code in PL/SQL - this was a standard architecture back in the client-server days of Oracle Forms. It is common practice to write a wrapper for the sprocs in Java and build the user interface on top of the wrapper.

One of the other posters mentioned that Subsonic can generate wrappers for the sprocs.

Once upon a time I had occasion to do a data dictionary hack that generated a proof-of-concept Java/JDBC wrapper for PL/SQL sprocs - IIRC it only took a day or so. Given that it's not that hard to do, I'd be surprised to find that there isn't quite a bit of choice in things you can get off the shelf to do this. In a pinch, writing your own isn't all that hard either.

I am a programmer, and I think I'm well educated in OO. I believe in a POCO (C#) and a model that only has get/set methods to encapsulate data. 3 layer domain models.

I'm looking for documentation that support value for having a simple domain model and all business logic in the service layer and a DAL for data access.

Martin Fowler:

is saying that a (anaemic) domain model has no value, and for it to have value it must handle the buslogic or/and data CRUD operation. I need some good books that has some counterarguments for Martin Fowler. (this is not a case of dismissing Martin Fowler, I respect the work. I'm looking for a better understanding of what we are doing and why? )

You can find counterarguments from... Fowler himself.

PoEAA, p. 110, Transaction script :

However much of an object bigot you become, don't rule out Transaction Script. There are a lot of simple problems out there, and a simple solution will get you up and running much faster.

A Transaction Script is not exactly the kind of service you describe (it might not use domain objects, even anemic ones), but it's pretty close.

Also, note that the notion of POCO doesn't assume anything about the dumbness or anemic-ness of an object. You can have rich domain POCOs with behavior in them. POCO/POJO describes a simple native object, as opposed to an object decorated with annotations or attributes, or that inherits a special class from a framework, often for persistence purposes.

I am learning Spring Data JPA, and I came across the term "JPA repository" (to be specific Spring Data JPA repository). I want to understand if the term "JPA repository" is a general concept (like JPA - a standard specification) or coined by Spring Data project?

What exactly does "repository" in this context means?

What exactly does "repository" in this context means?

Repository is one of the patterns introduced in Patterns of Enterprise Application Architecture (Martin Fowler, 2002). In the book, Repository defined as:

Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects

A system with a complex domain model often benefits from a layer, such as the one provided by Data Mapper, that isolates domain objects from details of the database access code. In such systems it can be worthwhile to build another layer of abstraction over the mapping layer where query construction code is concentrated. This becomes more important when there are a large number of domain classes or heavy querying. In these cases particularly, adding this layer helps minimize duplicate query logic.

A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction. Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes. Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer. Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers.

Further Reading

For more detailed discussion about Repository pattern, you should take a look at Patterns of Enterprise Application Architecture (Fowler, 2002) and Domain Driven Design (Evans, 2003).

I have a requirement where I need to insert into database from the object which has information about table name and values for each column. Could you please give suggestions on the best way to implement this with Hibernate.

Java Classes

public class InsertDataDetails {
  public String tableName;
  public List ColumnDetails> columnDetails;

public class ColumnDetails {
  public String columnName;
  public String columnValue;

At present I am thinking to create a native query and execute it with Session.execute query. However I am looking for better design where we can use DTO classes and hibernate features.

All of these proposals are far too relational-centric and simplistic. I'd recommend that you abandon this approach.

You should be thinking about objects in terms of the problem you're trying to solve, not persistence. If you want to use Hibernate, it can map your OO representation of the problem onto a relational schema.

I'd also recommend that you read Martin Fowler's Patterns of Enterprise Application Architecture to see how persistence problems are commonly solved in terms of objects.

Google for Data Access Object. Here's a simple generic one that's easy to implement with Hibernate and extend:

package persistence;

public interface GenericDao<K, V> {
    V find(K id);
    List<V> find();
    K insert(V value);
    void update(V value);
    void delete(V value);

Persistence in terms of objects has been solved many times over, as best as it can be done. What you've proposed does not represent a meaningful improvement over the state of the art.

I have a third party C# library for ldap operations. It does all operations on connection object as below:

LdapConnection connection = new LdapConnetion(Settings settings);
connection.Search(searchOU, filter,...);

which I feel is not readable. I want to write a wrapper around it so that I should be able to write code like below:

As I would like to have different Ldap classes like

public class AD: LdapServer { }
public class OpenLdap: LdapServer { }

and then

AD myldap = new AD(Settings settings);
myldap.Users.Search(searchOU, filter,...)
myldap.Users.Add(searchOU, filter,...)
myldap.Users.Delete(searchOU, filter,...)

I am thinking about Proxy design pattern, but things are not getting into my head about hot to go about it. What classes should I have etc.

Any help?

The solution posted above inherits from the LdapConnection. This is good if you want to maintain the inheritance chain, but I dont think that is necessary in your case. You simply want to customize and simplify the interface.

The proxy design pattern inherits from the underlying object so that the proxy object can be used anywhere that the underlying object is required, this is good if you want to "inject" extra functionality into the class without the clients of that class realising. I dont think this is your intention here?

The big problem with the solution posted above is that (because it inherits directly from LdapConnection) you can call search in two ways like so:

Settings settings = new Settings();
AD myAD = new AD(settings);

object results = myAD.Users.Search();
// OR
object results2 = myAD.Search();

As I'm sure you can see from the code, both of these call the exact same underlying method. But in my opinion, this is even more confusing to developers than just using the vanilla LdapConnection object. I would always be thinking "whats the difference between these seemingly identical methods??" Even worse, if you add some custom code inside the UsersWrapper Search method, you cannot always guarentee that it will be called. The possibility will always exist for a developer to call Search directly without going through the UsersWrapper.

Fowler in his book PoEAA defines a pattern called Gateway. This is a way to simplify and customize the interface to an external system or library.

public class AD
    private LdapConnection ldapConn;
    private UsersWrapper users;

    public AD()
        this.ldapConn = new LdapConnection(new Settings(/* configure settings here*/));
        this.users = new UsersWrapper(this.ldapConn);

    public UsersWrapper Users
            return this.users;

    public class UsersWrapper
        private LdapConnection ldapConn;

        public UsersWrapper(LdapConnection ldapConn)
            this.ldapConn = ldapConn;

        public object Search()
            return this.ldapConn.Search();

        public void Add(object something)

        public void Delete(object something)

This can then be used like so:

AD myAD = new AD();
object results = myAD.Users.Search();

Here you can see that the LdapConnection object is completly encapsulated inside the class and there is only one way to call each method. Even better, the setting up of the LdapConnection is also completely encapsulated. The code using this class doesn't have to worry about how to set it up. The settings are only defined in one place (in this class, instead of spread throughout your application).

The only disadvantage is that you loose the inheritance chain back to LdapConnection, but I dont think this is necessary in your case.

I have two classes Parent and Child.

class Child extends Parent {
    private String extraField1;
    private String extraField2;

Child class has 2 extra fields extraField1 and extraField2.

Q1. Should I make two diff. tables in the databse: one for Child and other for Parent?


Q1. Should I add two columns in the Parent table (each column for one extra field) and store the Child in the Parent table.

=============================== EDITED =======================================

Yes, Child and Parent are classes in the same hierarchy.

Patterns of Enterprice Application Architecture covers this as well in its chapters on Single-table inheritance, Class-table inheritance, and Concrete-table inheritance.

The coverage is similar to what Pascal has said. There's no One True Way, but the book does give you a good breakdown of costs and benefits, e.g.

The strengths of Concrete Table Inheritance are:

  • Each table is self-contained and has no irrelevant fields. As a result it makes good sense when used by other applications that aren't using the objects.
  • There are no joins to do when reading the data from the concrete mappers.
  • Each table is accessed only when that class is accessed, which can spread the access load.

The weaknesses of Concrete Table Inheritance are:

  • Primary keys can be difficult to handle.
  • You can't enforce database relationships to abstract classes.
  • If the fields on the domain classes are pushed up or down the hierarchy, you have to alter the table definitions. You don't have to do as much alteration as with Class Table Inheritance (285), but you can't ignore this as you can with Single Table Inheritance (278).
  • If a superclass field changes, you need to change each table that has this field because the superclass fields are duplicated across the tables.
  • A find on the superclass forces you to check all the tables, which leads to multiple database accesses (or a weird join).

I have used RIA service before, now testing Breeze Sharp.

RIA as well as Breeze give an impression that what you see on the server/middle tier is what you see on the client. To support that, the term Entity is being used on both the client and the server. Is it really an Entity, or it really a Presentation Model or Model on the client?

For smaller systems having one or two level entity graphs, there may not be wrong in thinking both the client and the server is the same. For larger systems with graphs going deep into five or six levels, the entities need to be converted to a DTO to make it simple. Unless the UI has some CRUD screens for entities, large applications end up with more DTOs and less entities. Most of the time, these DTOs will represent what UI wants and is equivalent to a presentation model.

Why can't we consider what we deal with at the client as presentation models rather than entities?

You are free to call the client-side entity class whatever you like :-)

More seriously, let's get at the typical reasoning behind the claim that this is an anti-pattern.

The client is not the presentation layer

I want to be super clear about this. Breeze is designed for rich web client applications. A Breeze client is not a presentation layer; it has a presentation layer. It also has its own business model and data access layers.

The terms "entity" and "DTO" mean different things to different people. I like Evan's DDD definition for "entity" and Fowler's definition for "DTO" in PoEAA.

Breeze client entities qualify as Evans entities: "Objects that have a distinct identity that runs through time and different representations. You also hear these called 'reference objects'" [Fowler]. Breeze entities aren't just property bags; they have business logic as well and you can extend them with more of your own.

Breeze entities are not "presentation models". They are independent of any particular UI representation and typically do not implement presentation concerns.

They are designed such that they can be bound directly to visual controls. That's a Breeze productivity design decision ... a decision about how we implement entities. Some people - the people who think entity properties are an anti-pattern - will hate that. Evans is silent on that question. Fowler poo-poos it. If it offends you, you may not like Breeze. Move along.

Send Entities or DTOs?

I'm about to argue that this is a false dichotomy.

People often say "it's an anti-pattern to send entities over the wire. Always send DTOs". There is sound reasoning behind this poorly worded edict. When a client and server entity class are identical, you've coupled the server's implementation to the client's implementation. If the model changes on the server, it must change on the client and vice-versa even if the change is only relevant on one of the tiers. That can interfere with your ability to evolve the server and client code independently. We may accept that coupling as a matter of expedience (and expedience matters!), but no one wants it.

A Breeze client entity class does not have to be the same, neither in shape nor in business logic, as the server entity class. When you query in Breeze, you put entity data on the wire and transform it into client entities; when you save, you put client entity data on the wire and transform it on the server into server entities. DTOs may be involved in either direction. The important fact is that the classes can be different.

They are conceptually related of course. You'll have a devil of a time transforming the data between the two representations if the meaning of the Customer entity diverges widely on the two sides. That's true with or without explicit DTOs.

Let's acknowledge as well that it is easier to transform the data in both directions when the classes are actually the same. You pay a mapping tax when they are different and you may lose the ability to compose Breeze LINQ queries on the client. You can pay the tax if you wish. Breeze doesn't care.

My inclination is to start with the same classes on both sides and change them when and as necessary. That has worked well for a high percentage of classes in RIA Services and DevForce. Most importantly, it has never been difficult for me to re-factor to separate classes when the need arose.

<rant> The worrywarts exaggerate the risks of sharing class definitions and understate the cost of mapping layers whose benefits are rarely realized in practice during the lifetime of the application.</rant>

When to use presentation models

You wrote:

For larger systems with graphs going deep into five or six levels, the entities need to be converted to a DTO to make it simple. ... Most of the time, these DTOs will represent what UI wants and is equivalent to a presentation model

In my experience that is only true if you assume that your client simply pastes entities to the screen. But I have already stipulated that the client is an application, not the presentation layer.

I further argue that you need a domain model on the client for the same reason that you need one on the server: to reason about the domain. You do this independently of the presentation. I assume that your entities will appear in some fashion on multiple screens subject to differing presentation rules. It's the same model, presented many ways. We call this "pivoting around the data".

No matter how many faces you put on the model, the underlying model data and the business rules that govern them should stay the same. That's what makes it a "Domain Model" and not a "Presentation Model."

FWIW, I always have a "Presentation Model" (AKA "ViewModel") in my apps to orchestrate the activities of a View. So I don't ask myself "PM or Model?". Rather I choose either to data bind visual controls directly to model entities that I expose through the VM's api or I bind them instead to an intermediate "Item Presentation Model" (AKA "Item ViewModel") that wraps some entities. Which way I go is an application decision. In practice, I start by binding directly to the entities and refactor to an "Item ViewModel" when and as needed.

In either case, I will construct the PMs (VMs) that I need on the client. If I need an "Item ViewModel", I create that on the client too. I do not ask my server to prepare DTOs for my client to display. To me that is an anti-pattern because it couples the server to the client.

How? If the developer needs to change a screen on the client, she may have to wait for someone to provide the supporting server endpoint and DTO. Now we have to coordinate the release schedules of the server and client even though the impetus for the change was a client requirement, not a server requirement.

Service pollution

It's actually worse than that. Some server-side developer has to stop what she's doing and add a new service method to satisfy a client requirement. That wasn't one of her requirements ... but it is now. Over time the service API expands enormously and soon it is full of look-a-like members that do apparently the same job in slightly different ways.

Eventually we forget who is using which method and what for. No one dares change an existing method for fear of breaking an unknown client. So the dev copies something that kind of looks right, make it a little different, and calls it something else. This pattern of service API pollution should sound familiar to anyone who has worked with enterprise applications.

Making exceptions

Every seeming "rule" is meant to be broken. Of course there are occasions when it is both expedient and efficient to let the server prepare data for display. This happens most frequently with high volume, read-only data that summarize an even larger volume of complex data on the Data Tier. When I go this route, I'm typically motivated by performance considerations. Otherwise, I stay true to the entity-oriented architecture.

When it looks like everything in my app conforms to the exception, I conclude that I've got the wrong architecture for this particular application ... and this shouldn't be a Breeze app. I don't know if this is your case or not.

Hope this helps.

I'm just getting into how to write a good architecture of a good software system, and I'm learning how to separate high level components into Layers. In this case, I'm trying to use Tiers, so as to model each Layer as a black box.

There are 4 tiers in my architecture: Presentation, Application Services, Business Logic, and Domain/Persistence. For the purposes of my question, we really only need to focus on the Presentation and Application Services.

The Application Services Layer will contain a Service that allows tracking of a certain event. The Presentation will have several views that should update dynamically as the tracking model of the events change. Inherently, it seems that I need a one-way change-propagation mechanism.

Since I'm trying to model these Layers as Tiers, I'd like to restrict communication between Facade objects for each Tier, and when necessary, allow a Tier to aggregate an object from one Tier lower, though only known by interface.

I'm programming this application in Java, so the obvious thing to use is Observable/Observer. However, I don't like that the update method for the Observer interface forces you to cast object arguments. I want to work around this by defining my own interface and class for this mechanism. The problem, then, is that the Application Logic will depend on an interface from the Presentation Tier, a certain no-no for this architecture. Is this a sign that I should try modeling with MVC fore-most and Layer the Model? Or would it be a better idea to model each of the views with an interface known in the Application Services Layer. It seems like a bad place to put it, and I'm stuck. Also, I'm using the View-Handler design pattern to handle the multiple views.

It seems to me that your question is less about Publish/Subscribe than it is how to get the layers to communicate.

Short answer:

Use MVC/MVP. Look up blog posts about them, download source code, and remember: if all you have is a hammer, everything looks like a nail. Meaning don't apply patterns because you have them, apply them because you need them.

Long answer:

If you're working in Java, I suggest Head First Design Patterns which will get you oriented to the way of thinking in patterns. After you have your head around design patterns, which I think you're on your way to now, you can look at Patterns of Enterprise Application Architecture. Feel free to skip Head First, but it is a very good book that I highly recommend if you're getting into architecture.

Once you've digested the Fowler book, or at least have a basic understanding of N-Tiered Enterprise Architecture, you should be well on your way.

I've been getting to grips with MVC (in PHP) by way of Zend. My understanding of the Zend Framework is that each type of user request maps to a specific controller (which in turn may or may not map to a model), and each action maps to a view. I've noticed the same pattern in Codeigniter and Kohana, and to some extent also in Symfony. Effectively, the URL maps thus: parameters...

Is this always the case with MVC? In what way is this different from Page Controller as a design pattern?

Zend Framework uses Two Step View. It's very similar to MVC. As you can see, theres not so much correspondence between the architecture and the url mapping.
If you want to learn about likely architectures, read PoEAA by Martin Fowler.

i want to learn entity framework. i started with some EF tutorials and i also know little about linq to sql.

i want to learn through a pet project. project should be in three layers. web forms (prez), data layer(c# lib), bussiness layer(c# lib). Project can be any, any functionality. just want to learn how to use EF in diff. layers and in UI.

can anyone guide me how do i start to do layering? help me to learn how should i use EF objects from DAL layer to BL and then UI.

I am confused as all tutorials shows direct binding of EF to EF datasource in UI and with controls.

thanks a lot.

A couple of things I would recommend:

  • Rob Conery (with occasional guests) put together a video series on building a storefront site using ASP.NET MVC. He used LINQ-to-SQL, not Entity Framework, but I don't think the difference is significant to what you are interested in learning. One nice thing about this series is that he walks you through the various design decisions he makes, and even backtracks when he later feels that one of them was wrong. Another is that, in addition to MVC and LINQ-to-SQL, he also explores some other development concepts such as inversion of control and test-driven development.

  • Martin Fowler's book Patterns of Enterprise Application Architecture is a great resource for this sort of thing. He lays out the different patterns that are available in each tier of your application and discusses how to use them and when each is appropriate. Fowler's writing style is friendly and easy to read, and a lot of the patterns in his book are prominent in the vernacular of the software development world today (e.g. Repository pattern, Active Record, Unit of Work).

Hope this helps!

I would like to know a good introducing book for Repository Pattern using Entity Framework. Do you know any? thanks

Read the book about Entity Framework, relevant parts from the book about enterprise application patterns and the book about domain driven design. You must first understand every single part to use it correctly.

Once you understand topics answer few questions:

  • Why do you need repository?
  • What will repository solve for you?
  • Why is EF itself not sufficient for that?
  • Will it help if you wrap EF to repository?
  • etc.

Until you don't know at least expected answers for these questions you don't need to bother with repository pattern. The main rule of pattern usage: A pattern should be used when it is needed not because it exists. The boom of all these repository articles goes against this rule and moreover most of these articles are wrong using either wrong code (like passing Func<> to queries instead of Expression<Func<>>) or bad assumptions (like saying that using repository will make your code unit testable).

Let's say I have a POJO class Meal. This class is mapped with an ORM (e.g. JPA + Hibernate), so I can persist it in a DB. Among other things, this class contains a List<Dish> dishes (Dish being another mapped POJO) that is lazily loaded by the ORM.

Now I have a business layer method Meal getNextDueMeal(). This is invoked by the UI layer to then display the meal to the user. Of course, the dishes that make up the meal should also be displayed.

But how should I deal with this? If I try to iterate over the list returned by getMeals() naively, I would get a LazyInitializationException. I could maintain an EntityManger in the UI layer e.g. by using Spring's @Transactional annotation. But then the object returned from the business logic would stay persistent, i.e. if I somehow modify the Meal-"POJO" in the UI, it will automatically get saved once I return from the @Transactional-method, which may not be what I want.

tl;dr: Should the business layer return persistent objects to the UI-Layer? And if not, how do I deal with lazy loading?

When you're working with a remote interface, it's not a good idea to return your entities as your Business Layer return values. You can define some DTO or Data Transfer Objects and populate them from fetched entities and return those DTOs as the return value.

Should the business layer return persistent objects to the UI-Layer? And if not, how do I deal with lazy loading?

About Lazy Loading, you can populate all the required values in the business layer into the DTO object, hence, in your UI layer all the required attributes are loaded and you won't encounter those LazyInitializationException exceptions.

How it Works?

Quoting from PoEAA:

The fields in a Data Transfer Object are fairly simple, being primitives, simple classes like Strings and Dates, or other Data Transfer Objects. Any structure between data transfer objects should be a simple graph structure—normally a hierarchy—as opposed to the more complicated graph structures that you see in a Entity.

In your case, you probably would have a MealDto and a DishDto, something like this:

public class MealDto {
    private String name;
    private List<DishDto> dishes;

    // getters and setters

You can use another abstractions responsible for assembling the DTO from the corresponding Entity. For example, you can use a MealAssembler:

public class MealAssembler {
    public MealDto toDto(Meal meal) {
        MealDto dto = new MealDto();
        // populate the other stuff    

        return dto;

New to PHP & OOP so bear with me... I'm in the optimistic early stages of designing and writing my first PHP & OOP website after a lifetime of writing crappy M$ VBA rubbish.

I have a class "User" which has a save method with the relevant database calls etc... (actually I have DB and DBUtils classes that handles the connection and CRUD - my business classes just call select, update, delete methods on DB Utils and pass associative arrays of data)

Anywho... My "User" class is extended by an "Admin" class which has some additional properties over and above "User" yada yada...

What is the best way to deal with the save method on "Admin"? I understand that if I add a save method to the Admin class it will supercede the one on User but I don't want it to. I want to write the save method on Admin to only deal with the properties etc that are specific to the Admin objects and for the properties inherited from "User" to be dealt with in the User save method.

Does that make sense? Is it a specific OOP pattern I'm looking for? Any help or guidance with how I should design and structure this code would be appreciated.

EDIT: Whoa! Thanks for all the answers below. Not sure which is my preferred yet. I will have to do some playing around...

You main issue stems from fact that you have been ignoring one of core ideas in OOP: single responsibility principle .. then again, it seems like everyone who provided "answers" have no ideas what SRP is either.

What you refer to as "business logic" should be kept separate from storage related operation. Neither the instance of User no Admin should be aware oh how the storage is performed, because it is not business logic.

$entity = new Admin;
$mapper = new AdminMapper( $db );

$mapper->fetch( $entity ); 
//retrieve data for admin with that name

$mapper->store( $entity );
// rename and save

What you see above is an extremely simplified application of data mapper pattern. The goal of this pattern is to separate business and storage logic.

If, instead of instantiating the mapper directly $mapper = new AdminMapper( $db ), it would be provided by an injected factory $mapper = $this->mapperFactory->build('Admin') (as it should be in proper codebase), you would have no indication about the storage medium. The data could be stored either in an SQL DB or file, or some remote REST API. If interface for mapper stays the same, you can replace it whenever you need.

The use of factory would let you avoid tight coupling to specific class names and, in case of mappers for SQL databases, let you inject in every instance same DB connection.

To learn a bit more about it, you could read this, this and this.

But, if you are seriously thinking about studying OOP, then reading this book is mandatory.

So I've been looking up more tutorials and articles about the MVC design pattern to deepen my understanding of them and I'm starting to doubt if I have been doing it all wrong. So yeah the goal of those patterns are to make code reusable and to minimize repeated code, correct?

I've been seeing various ways of how those design patterns are explained which are confusing me a bit. In the past I thought it was the controller-as-a-mediator-between-model-and-view way, but now I'm learning that that was wrong and that the view is actually much more than just a template. Then I also read somewhere (I think here) that in a true MVC pattern, there is by definition only one model and all the other "models" are just different facets of the single model. Is this the case? Is this the best way to separate code and make it reusable? How would that look like in code? And again somewhere else I read that for web-applications it is better to stick to the MVVM pattern.

So now I'm a bit confused. What IS the most effective pattern to separate concerns in a web-application and make the code reusable? I would prefer to not only see a description of this pattern, but also a short example in code so I understand it better.

So yeah the goal of those patterns are to make code reusable and to minimize repeated code, correct?

Is this the best way to separate code and make it reusable?

Nope. It really isn't.

The goal in MVC and MVC-inspired patterns is to isolate business logic (model layer) from the user interface. And within the UI - to divide it into managing input and output.

Basically, MVC and MVC-inspired patterns are arcitectural design patterns that implement principle know as Separation of Concerns.

Then I also read somewhere (I think here) that in a true MVC pattern, there is by definition only one model and all the other "models" are just different facets of the single model. Is this the case?

No. Model is not a "thing" (class, object). It is a layer. Same way as you could say that all of controllers and views are contained in presentation layer or UI layer.

What people refer to as "models" are usually either domain objects or (much worse case) some form of active record implementation.

And again somewhere else I read that for web-applications it is better to stick to the MVVM pattern.

MVVM pattern add another layer between views and the model layer. It's best used for situations, when you either cannot controller the implementation of the views or/and the model layer.

Most of people confuse it with use of presentation object (M.Fowler has this nasty habit of adding "model" to everything, which create boundless confusions) concept. Presentation objects are meant to isolate reusable parts of UI logic.

How would that look like in code?

MVC and MVC-inspired patterns are created to manage large codebases. You apply MVC patter when simple use of object oriented practices are not enough to make code understandable. You do it by adding additional constraints to your codebase. MVC does not add anything new to your application. Instead it restricts where and what code can be written.

And "sort code example" will not actually illustrate the pattern. To actually understand, how it works, you should read something like PoEAA book .. or something similar.

What IS the most effective pattern to separate concerns in a web-application and make the code reusable?

It's a matter of opinion.

The official website seems only provided some tutorial on how to use:

But I want to know why the directories should be setup like this

Symfony is based on a lot of patterns, this blog post highlights a few of them:

Basically, it's a model-view-controller (MVC) framework and the directories are setup like that only to organize the numerous configuration and PHP files that are created during a normal, structured project. Of course, you'd need to be a little bit more specific on what makes you curious about the directory structure but if you go through the documentation, you'll find interesting facts about how your project will be divided. The directory structure is not necessarily related to a specific design pattern itself (the code is) but probably more related to just getting your files organized.

Anyway, Symfony is a PHP framework like many others, and just by going through generic design patterns using classic books such as Patterns of Enterprise Application Architecture or websites about PHP patterns recipes, popular patterns or extensive lists, you should get a good idea on the general structure.

We are starting a new Java EE project and am looking for suggestions regarding design patterns to expose the backend interfaces.

It would be preferable if the backend logic can run seamlessly on Tomcat, other Java EE 5 containers. We are currently veering towards Java EE 5, EJB3, JPA and the preferred deployment platform is JBoss 5 AS. We would expect the backend engine to expose the following interfaces (e.g. EJB3 local / remote, SOAP, REST) for the business logic. Any pointers regarding suitable design patterns which can be used as for as code layout and package structure is concerned, which will enable us to package and deploy them on the above mentioned containers.

What are good priciples for creating a scalable website predominantly C#? What design patterns are more common for a C# based website? Links to good books or articles are welcome.

Martin Fowler's Patterns of Enterprise Application Architecture (summaries on his website) are a good place to start. There's an awful, awful lot of components and technologies that can go into building a scalable website... load balancing, caching, application serving, database setup, networking, and somewhere in there is the actual code being written.

As we define view,controller,service and Dao layer in application then how data flow in between them.

e.g. suppose we add struts,spring,hibernate,etc. jars in project then how they work together?

The MVC pattern itself does not describe how should you implement your web application. What it describes is how your components should interact with each other in order to achieve a modular architecture with replaceable components.

The pattern is explained in details in Martin Fowler's POEAA and in Wikipedia. More info about MVC can be found in Wikipedia

A simple example using Java, Spring and Hibernate

In this case Spring MVC provides a pluggable framework where you can define your models , controllers and views without coupling them together too tightly (this is achieved through IOC/DI).

The first thing to notice is the DispatcherServlet which is a regular servlet that serves as an entry point by handling all the incoming HTTP requests and routing them to their respective controllers. The appropriate controller is looked up by their mappings, eg. via @RequestMapping annotations.

The controller's responsibility is to determine what actions should be performed as a response to the incoming request. This is usually done by checking headers, parameters, session info, path for information what the user wanted to do. Here is an extremely simple example:

if (session.getAttribute("authenticated") == false) {
    // we need to redirect to the login page
} else {
    // everything was fine, so we do some business logic in the model

Then the control is passed to the model layer where business logic happens. This may include any operation that changes the model's state, like updating a password, registering a booking, clearing transactions, and so on. In web applications these operations often involve the use of a persistence API, eg. Hibernate.

public class ImportantService {
    public void doSomethingVeryImportant(final ProductOrder order) {
        // Here we define the business operation

        // An additional pseudo-persistence operation

In practice when the model has finished then control is returned to the controller which decides how to update the view (eg. redirecting the browser or just simply display a result page) where the user sees the result of his/her action.

A lot of applications with a GUI can be seen as handling a collection of objects (probably at several levels). For instance, a list of contacts or a set of documents. Moreover, maybe there exists the concept of "current object" (current contact, current document or the like) in the application and some GUI controls make actions happen on this current object (and not on other objects in the collection). Obviously, the GUI should offer a way for selecting a different object as "the new current one" before applying new actions on it. I think it is a quite general situation, so maybe there is a quite general solution to where to place such a concept (for instance, an integer index on a list) in the MVC pattern.

I feel it should be out of the Model (I can think of an application with several View/Controller pairs sharing one Model and where each View has its own opinion on which object is the selected or current one), but I have not been able to confirm it by "googling".

I would like to know pointers to authors discussing this subject. Moreover, your opinion is welcome (if such kind of discussion is allowed in this forum). Thanks.

Disclaimer: my primary language is PHP, and only have experience with MVC-related patterns in the context of web (mostly with the Model2 variant of it, because of the obvious limitations of web itself), which has shaped my understanding of MVC structure.

I see the concept of Current Object as an aspect of Model Layer's state. Current object should not directly exposed to other parts of MVC triad. Both the controller(s) and view(s) have only access to it via the higher/public part (I tend to call that part "Services", but it's a bad name) of the model layer.

This lets you freely change, manipulate and swap objects, which you have marked as "current". At the same time other parts of MVC are not directly affected.

As for the materials on subject, I have not really seen any articles/books dealing exclusively with this subject. The best I can suggest is reading Patterns of Enterprise Application Architecture .. again.

At the moment, I've got a fat controller and a thinner model layer.

My controller looks something like this.

namespace controller;
class home

    public $template = 'home';

    protected $database;

    public function __construct(\Zend\Db\Adapter\Adapter $database){
        $this->database = $database;


     * Returns the home page
    public function indexView(){

        $userService = new UserService($this->database);
        $view = new ViewModel($this->template);
        $view->assign('pageTitle', 'Home');
        $view->assign('lead', "Welcome ".$userService->getFirstName());
        $view->assign('h1', 'Home');


My model would consist of data manipulation, data gathering etc.

The viewModel class this calls, the view, is basically a container class which includes the header, footer and the actual template used inside.

In terms of MVC, I now understand that the Model and View are aware of each other.

Am I going about this the right way?

Short answer: no, you are not doing it the right way, or even slightly correct-ish way.

The MVC design pattern is all about separation of concerns. You separate the model layer from presentation layer, to split the domain business logic from how it is demonstrated.

In presentation layer you split the components that are responsible for user interaction (controllers) from those that govern the UI creation (views).

The model layer too is subject to some separation, though that usually is not covered in "mvc for beginners by beginners" blog posts. I wrote a short description in an earlier post. But if you want to actually understand how to implement model layer, you will have to read Folwer's PoEAA.

In classical MVC (which you cannot use for web) and Model2 MVC patterns the view request all the data that i need from model layer. Controller only changes state of model layer and current view by applying user input the them.

In the simplest implementations of other MVC-inspired design patterns (MVVM and MVP) the controller-like structures (ViewModel and Presenter - respectively) provide view with the data from model layer. That also means that having a viewmodel inside a controller makes no sense whatsoever. You can read more about MVP pattern in this publication.

P.S. also, why are you injecting DB connection in the controller when all you will do with it is to pass it along? That code fragment is violating LoD. If you need to acquire structures from model layer inside a controller, you should be injecting a factory instead.

Do you have good literature recommendation for Design Patterns, especially for Data Access layers.

I'm searching for patterns like Repository and Unit of Work. I need those for implementing WebServices, MVC web applications and MVVM desktop applications.

If you are searching specifically for Repository and Unit Of Work patterns then i suggest that you don't read full books because they discuss them i a generic way and you will get overwhelmed, instead look for specific implementations for those patterns in the technology area you are working in.
With that being sad, the two authors that stand behind Repostiory and UnitOfWork patterns are Martin Fowler and Eric Evans with their books Patterns of Enterprise Architecture and Domain Driven Design: Tackling Complexity at the Heart of Software respectively, the latter book is followed by a great book called Applying Domain Driven Design and Patterns with Examples in C# and .NET.
Regarding design patterns in general the authoritative reference is The GoF (Gang of Four) book Design Patterns: Elements of Reusable Object Oriented Software System and a very great book that focuses on the most common patterns in an entertaining manner is Head First Design Patterns.

I am about to create a project where I want to have a class that connects my application to a database.

I want to do this in the best object-orientated way, following the Solid principles!

My question to you is:

Is it ever smart to divide your Provider into subclasses, for example a subclass that gets information from the database and a subclass that can insert data into the database? Or do you keep these functionalities in one huge class?

I'd recommend that you take a look at Martin Fowler's Patterns of Enterprise Application Architecture. He's got a nice chapter on patterns for persistence.

This problem has been solved many, many times: ORM solutions like JPA and Hibernate, iBatis mapping, Spring JDBC. I can't imagine how you'll improve on what's been done before. If you can't articulate what's different, I'd recommend using something that's been written, tested, and proven before investing in something new.

If you must, I'd recommend a generic DAO. Here's a very simple one:

package persistence;

public interface GenericDao<K, V> {
    V find(K key);
    List<V> find();
    K save(V value);
    void update(V value);
    void delete(V value);

I am a database / SQL / ADO.NET newbie, and I'm trying to build a solid foundation before I try to learn about ORM frameworks like NHibernate or Entity Framework. I have been reading up about platform-agnostic RDBMS concepts, and now I'm trying to adapt that to writing clean and reusable C# code that actually interacts with a database. I've heard of Martin Fowler's Patterns of Enterprise Application Architecture which has been recommended here before, but the "Enterprise" in the title makes me wonder if there's not some intermediate learning step I need to make before I'm ready to read that book.

As practice, I'm making a simple ASP.NET web site that helps visitors look up certain information from a database that has a few thousand records. It's a painfully simple first project--there are no user accounts or logins of any kind, and the site would get about a dozen hits per day.

My ASP.NET code features a few methods like this to retrieve data from the database:

string dbConnectString = "...";

public List<string> GetItems()
   List<string> rList = null;

   using (SqlConnection myConn = new SqlConnection(dbConnectString))
      string queryStatement = "SELECT Name FROM SomeTable";

      using (SqlCommand myCmd = new SqlCommand(queryStatement, myConn))
         DataTable resultTable = new DataTable("Results");
         using (SqlDataAdapter myAdapter = new SqlDataAdapter(myCmd))
            if (myAdapter.Fill(resultTable) > 0)
               // This loop should probably be a LINQ expression
               rList = new List<string>();
               foreach (DataRow row in resultTable.Rows)


   return rList;

I think I've done the right thing as far as handling the objects that implement IDisposable. But is there a better way to write the method itself?

Here are some questions that I have:

  1. From what I've read, it seems that connection pooling makes it OK to instantiate a new SqlConnection with each call to methods like GetItems(). Is there a "cleaner" way to write the code, so I still do proper resource management, but don't have so much repetition in blocks like using (SqlConnection ...)? How about this approach:

    public class DatabaseManager : IDisposable
       protected SqlConnection myConn;
       public DatabaseManager(string connectionString)
          // Set up the constructor
          myConn = new SqlConnection(dbConnectString);
       // IDisposable implementation stuff goes here.  Any usage of 
       // DatabaseManager would have to take place in a using() block.
       public List<string> GetItems()
          List<string> rList = null;
          string queryStatement = "SELECT Name FROM dbo.SomeTable";
          using (SqlCommand myCmd = new SqlCommand(queryStatement, myConn))
             DataTable resultTable = new DataTable("Results");
             using (SqlDataAdapter myAdapter = new SqlDataAdapter(myCmd))
                if (myAdapter.Fill(resultTable) > 0)
                   rList = new List<string>();
                   foreach (DataRow row in resultTable.Rows)
          return rList;
  2. Aside from my shameless use of vertical spacing, is there a more elegant way to extract the List from the result of the database query? One way would be to replace the foreach() iteration with a LINQ call, but that would only save two or three lines of code.

Thanks guys!

Your code is neither clean nor reusable:

  1. The sql query and column name are hardcoded into the manager class which makes is necessary to have an extra manager for each single table. You could possibly solve this by allowing actual queries to be injected but then you'll end up with a "manager of managers" with different responsibilities
  2. The lifetime of the sql connection is tied to the lifetime of the manager which makes it impossible to have a transaction over a compound database access
  3. There is no error handling
  4. Using a data adapter to first retrieve the data and then copy it to a list is less effective than using a data reader

To fix all these issues you need a lot of time and a lot of clever ideas. You have issues with a single manager with a single select query. How about dozens of managers, selects, updates, inserts, deletes with joins to other managers and all this with proper transaction scopes and error handling?

This is why people stick with ORMs when possible and do not reinvent wheels. Writing a good, reusable data access layer is not easy and although you could possibly have a working solution for one or two simple cases, this would not scale well because of reasons I've mentioned. Sooner or later you'll end up with a large pile of pure mess and after two or three unsuccesfull aproaches you would end up reinventing ORMs.

I am a self taught "developer". I use the term loosely because I only know enough to make myself dangerous. I have no theory background, and I only pick up things to get this little tool to work or make that control do what I want.

That said, I am looking for some reading material that explains some of the theory behind application development especially from a business standpoint. Really I need to understand what all of these terms that float around really talk about. Business Logic Layer, UI abstraction level and all that. Anyone got a reading list that they feel helped them understand this stuff? I know how to code stuff up so that it works. It is not pretty mostly because I don't know the elegant way of doing it, and it is not planned out very well (I also don't know how to plan an application).

Any help would be appreciated. I have read a number of books on what I thought was the subject, but they all seem to rehash basic coding and what-not.

This doesn't have to be specific to VB.NET or WPF (or Entity Framework) but anything with those items would be quite helpful.

In addition to some of the others (and after Code Complete), try Domain-Driven Design: Tackling Complexity in the Heart of Software.

I think most people would recommend Code Complete by Steve McConnell as the first book to read on putting some good software together.

I am creating a database for a web application and am looking for some suggestions to model a single entity that might have multiple types, with each type having differing attributes.

As an example assume that I want to create a relational model for a "Data Source" object. There will be some shared attributes of all data sources, such as a numerical identifier, a name, and a type. Each type will then have differing attributes based on the type. For the sake of argument let's say we have two types, "SFTP" and "S3".

For the S3 type we might have to store the bucket, AWSAccessKeyId, YourSecretAccessKeyID, etc. For SFTP we would have to store the address, username, password, potentially a key of some sort.

My first inclination would be to break out each type into their own table with any non-common fields being represented in that new table with a foreign key in the main "Data Source" table. What I don't like about that is that I would then have to know which table is associated with each type that is stored in the main table and rewrite the queries coming from the web app dynamically based on that type.

Is there a simple solution or best practices I'm missing here?

What you are describing is a situation where you want to implement table inheritance. There are three methods for doing this, all described in Martin Fowler's excellent book, Patterns of Enterprise Application Architecture.

What you describe as your first inclination is called Class Table Inheritance by Fowler. It is the method that I tend to use in my database designs, but doesn't always fit well. This method corresponds most closely to an OO view of the database, with a table representing an abstract class and other tables representing concrete implementations of the abstract class. Data must be queried and updated from multiple tables.

It sounds like what you actually want to use is called Single Table Inheritance by Fowler. In this method, you'd actually put columns for all of your data in one table, with a discriminator column to identify which fields are associated with the element type. Queries are generally simpler, although you do have to deal with the discriminator column.

Finally, the third type is called Concrete Table Inheritance by Fowler. In my mind, this is the least useful. In this method, you give up all concepts of having any kind of hierarchical data, and create a single table for each element type. Still, there are times when this might work for you.

All three methods have their pros and cons. You should consult the links above to see which might work best for you in your project.

I am looking to write some webservices.

What defines one unit of "service". I note that as apart of one project you can have multiple .svc service files.

How do you normally segment your services? For example, a banking app:

Would you have one service (.svc) for?

  • Client
    • AddClient(Client newClient)
    • DeleteClient(Client client)
  • Account
    • SetName(string name)
    • SetType(AccountType type)
  • Transfer
    • SendMoney(Client client, etc)
    • ReceiveMoney(Client client, etc)
  • HomeLoan
    • AddNewHomeLoan();
    • RemoveHomeLoan

Is there a method of grouping the entities? For example, instead of having a transfer service, you could put send and receieve money in account service because you receive and send out of accounts.

This also brings another question in regards to methods and parameters. If I wanted to add an edit client, would one normally add a method like EditClient(Client client, Client newClient), and replace the whole client with another client object? Or would you add separate methods for editing a client for example: EditName(Client client, string name) under Client service?

I'd like to properly lay out where the operationcontracts will fit in my web services.

I would suggest reading the Pattern of Enterprise Architecture by Martin Fowler. This should give lots of organisation tactics for service oriented software.

I am running into a problem to validate a model which refers to other models.

I have an 'user' model and a 'profile' model. I want to create the profile but I need to check if the user actually exists.

In my profile model I have a method 'validateUser' but I would either have to write a query to a specific table within a database or I have to create a user model object and call exists(id).

Both options seem to have a lot of drawbacks. The table name could change I would have to go over all models that use it. With the user mode object I would have to create an object within the profile model or inject it.

What is the best way to approach this?

The domain of doom ..

In real world situation the validation is rarely a straightforward process. Instead you have several unrelated concerns:

  • checking if data inside an instance is consistent with business rules
  • making sure that state of instance is not conflicting with other domain structures
  • verifying the integrity of information against existing data and constraints in storage

If you are using active record for representing your domain model (don't confuse with M in MVC), then all these three aspect become a responsibility of single object.

Which is what you have now.

But there is hope ..

The best option is to separate all these responsibilities (all hail SRP). Basically what you do is divide your current setup in thee different groups of structures:

  • domain objects: for dealing with specific rules of domain entity

  • data mappers: for storage abstraction

  • services: for interaction between domain objects and mappers (or other domain objects)

Since your question was somewhat confusing (the were users and profiles and saving and validation and then something wasn't there), I am not sure if I understood it correctly, but here is a small example:

public function createProfile( $id, $email, $name )
    $account = new Account;
    $account->setId( $id );

    $accountMapper = new AccountMapper( $pdo ); // explained below

    if ( $accountMapper->fetch( $account ) === false )
        $this->errors[] = .. something about missing account

    $profile = new Profile;
    $profile->setEmail( $email )
            ->setName( $name );

    if ( $profile->isValid() === false )
        $this->errors[] = .. something about invalid profile

        $profileMapper = new ProfileMapper( $pdo ); // explained below
        $profileMapper->store( $profile );
    catch ( Exception $e )
        $this->errrors[] = .. something about failing to create profile

    $account->addProfile( $profile );
    $accountMapper->store( $account );

This is extremely simplified example. Especially where mappers are initialized, because that part in real-world situation would be handles by some factory. Kinda like described in this post.

The point here is that the validation of domain data and and insurance of DB integrity is done separately. The underlaying APIs for interaction with database actually return you error code is you violate UNIQUE KEY or FOREIGN KEY or any other constraint, which you can then use to determine what went wrong.

The method itself would be part of a service (in this case - some service that manages user accounts).

Note: if your application needs to perform multiple SQL interactions per operation and those interaction need to be done as transaction with ability to do rollback, then, instead of using data mappers directly, you should be looking at implementing Units of Work. To learn about UoW, you will have to read Patterns of Enterprise Application Architecture, because it's really extensive subject.

I can't get this to work.


        function __autoload($classname){
            include 'inc/classes/' . $classname . '.class.php';


$travel = new queries();
echo $travel->getPar("price");


And this is the inc/classes/queries.class.php file.


 class queries {

        function getPar($par, $table='travel', $type='select') {

            $result = $db->query("
             $type *
             FROM $table
             $par LIKE
            while ($row = $result->fetch_assoc()) {

                return "



It returns "Class 'queries' not found". What's wrong with it?


Fatal error: Cannot redeclare __autoload() (previously declared in /index.php:5) in /index.php on line 5

What the hell? I can't redeclare a function that is already declared in its own line, why?

Instead of that dreadful abomination, you should learn how to utilize spl_autoload_register():

spl_autoload_register( function( $classname ){

    $filename = 'inc/classes/' . $classname . '.class.php';

    if ( !file_exists( $filename) ){
        throw new Exception("Could not load class '$classname'.". 
                            "File '$filename' was not found !");

    require $filename;


And you should register the autoloader in your index.php or bootstrap.php file, and do it only once per loader (this ability lets you define multiple loaders, but that's used, when you have third party library, which has own autolaoder .. like in case of SwiftMailer).

P.S. please learn to use prepared statements with MySQLi or PDO.


Since you are just now learning OOP, here are few things, which you might find useful:



I found an interesting discussion here:


DataSets are sub-par amateur solutions to code your Data layer...Stop Using Them and learn to CODE! :)

What is your opinion of DataSets vs. just stubbing out custom classes and working with those? What are other alternatives?

Snobbery aside, DataSets can be useful in applications with relatively straightforward business logic and where the developer has some control over the database schema, such that data tables match 1:1 business objects (which in this case are usually comprised of a DataRow).

Martin Fowler discusses this very clearly in Patterns of Enterprise Application Architecture (Amazon link). DataSets (Table Module in Fowler's nomenclature) are a good match to a Transaction Script, whereas a Domain Model requires more well defined classes and a mapper to the database (because a 1:1 correlation between business objects and tables is typically not achievable in this situation).

DataSets/Table Module have a lot of limitations, but they have advantages in simplicity, especially if you are working in .NET.

A pragmatic programmer will assess the requirements of a given application and apply patterns and technologies that fit best, even if they aren't the sexiest. For simple scenarios with straightforward 1:1 mapping to relational data, DataSets don't suck. Often, though, they do, and any programmer that relies on them exclusively is in for trouble in more complicated scenarios.

I have 2 tables, for now as an example, ClientOrder and Products Table. Using Linq, I have been able to write all the queries that I want to run 1. Search by Client order 2. Search by Client name 3. Search by Product name 4. Search by Product ID

I want to create methods for each of the above queries. The ? is, what pattern is appropriate here? Factory Pattern does not seem to fit the bill as I know that each of my object will be using the same data context.

Is it wiser to just create a static class with the 4 static methods?

Note: I am 5 months in with the programming world and a newbie

I found Martin Fowler's Patterns of Enterprise Application Architecture helpful in learning how people structure access to database tables. Some of these patterns are listed here.

For your simpler task, a single class with four static methods sounds perfectly reasonable. But you should consider Fowler's Table Data Gateway pattern, where you package all the access to each table in its own class of static methods (and use a standard naming convention).

I have been following the modified Model View Controller example presented in this article by Oracle. Java SE Application Design with MVC

In this example the DefaultController class declares property name strings like this:

public static final String ELEMENT_TEXT_PROPERTY = "Text";

These strings are used in multiple places.

In the controller:

AbstractController uses reflection to search its models for a method named set+propertyName.

In the Model:

The model has setter methods which call this method:

firePropertyChange(Controller.NAME_PROPERTY, oldName, name);  

In the View:

In the modelPropertyChange method,


The part that concerns me is that the model is referencing the controller's static fields. I am still trying to master MVC and I am unsure if this architecture achieves the desired decoupling that MVC is used for. Does it matter that the all three classes reference the controller's static fields?

EDIT: Is the architecture described in this tutorial, as coded, an invalid representation of MVC? If so, can it be altered so that the model / (model layer) is not dependent on the static property names defined in the DefaultController class?

I realize this article is "just a tutorial", but if the code presented in it does not reflect the claimed decoupling, I think that the community should stop referencing it as an example of MVC.

I am not Java (or even desktop application) developer, so take this all with grain of salt.

First of all, static fields in any code represent a global state, which is completely against any practices in object oriented code.

As for your worries, that the code in tutorial violates SoC, you are right. But then again , it is intended as a basic tutorial, and not something too advanced. The goal is to show the parts of MVC triad and give at least surface level comprehension of how they interact and what are the main responsibilities. It is not meant to be copy-pasted in production code.

Once clear sign for it would be, that there exists a "model object" in this code. In a real world situation model would be a layer.

If you want to gain more extensive understanding of MVC, i can recommend three reading materials:

I have been having a difficult time understanding how to separate my program into a n-tier application with 3 layers (BLL,DAL,UI). I have so much confusion on the subject that I don't know where to begin. I have looked at videos, articles, and application examples, but I find it hard to comprehend. There seems to be a lack of consistency from one example to the next. Is there any resource I can look at that is extremely thorough on the subject?

For reference, I am a C# .NET entry level developer, is this too big of a topic to tackle right now? I understand the concept completely, however I do not know how to implement it well.

You should read books like

Martin Fowler - Patterns of Enterprise Application Architecture

Dino Esposito - Microsoft® .NET: Architecting Applications for the Enterprise

But they can be too difficult if you are C# entry level developer (and not senior Java developer same time :))

Some overview and basic understanding you can get here or search some short and easy articles about this subject.

I have to design a school web ERP for a client of mine. The following modules need to be present as of now:

Please help me with the required links or book which can guide me with the steps that need to be followed to create the design. Difference between different designs that can be used for e.g. in one of the links i read that Component based design should be used.

Also, Please note that the modules need to be licensed. i.e. The user must be able to choose one or more modules of his interest and only those modules should be installed.

I am new to this area and this exercise is primarily for learning process so I WANT TO DO THIS FROM SCRATCH AND NOT USE THE EXISTING OPEN SOURCE AT THIS POINT OF TIME.

Please help me with the required links / books / papers etc...

This question is way too broad to be completely answered with a single post. But if you're looking for a book to explore architectural approaches I can highly recommend the following, which in my opinion is a must-read for every developer anyway:

Patterns of Enterprise Architecture by Martin Fowler

I have to develop an application which fulfills following demands:

  1. It has to be developed in .NET (C#/Visual Studio/Standalone windows application).

  2. The first important requirement is the visualization and manipulation of graph data. Here I will use "ZedGraph" as I can tell for the moment.

  3. The second requirement is a database connection. (SQL)

  4. The database has to be accessible via the companies intranet.

  5. Further some algorithmic functions have to be implemented in order to preprocess the given Graph-data before saving it to the database.

Certainly those are not all the requirements in detail but they briefly describe the main goals of the application.

Basicaly I could develop all the functions separately, drag & drop a GUI in Visual Studio's designer's, assign functionalities to the according GUI-elements etc. But this somehow wouldn't feel right. Especially for the following reasons:

  • I want to keep the application as extensible as possible.

  • It also should be maintainable

  • I could thing of many more reasons but that are the two which first come to my mind...

So my question is whether somebody can provide me with references for software architecture which would fit to this kind of project. Especially books are important, as the application is a part of my thesis, so every method and decision has to be justified with a reference.

Thanks in advance, BC++

I would definately go for Code Complete, it is not related to any programming language in particular, instead it discusses good and practizes, totally recommended

I'm building some application, the involves training programs. my issue is like this,

A workout could be simple as this:

3 sets of 45 push ups.

so I would just create 2 fields, sets / count

BUT a workout could be also:

45 minutes run, 3 sets of 45 pushups, 2 minutes of rope jumping, 150 meter swimming.

so i need to build one table, that would know to store the data as it changes it structure, and later I could still translate it to real data on the gui.

how can i make it efficiently and wisely ?


To make it a bit clear, i want to specify to each workout what Ive done in it. so one workout could be : 3 sets, first: 45 push ups second: 32 push ups third: 30 push ups

and another workout could be: 3 sets of pushups: first: 45 push ups second:32 push ups third: 30 push ups and also 2 minutes of jumping rope 150 meter swimming

the data isn't consistence, one set could be a number of push ups, the next could be a time length etc..

You may want to consider a database schema such as the following:

CREATE TABLE workouts (
   workout_id  int,
   user_id     int,
   PRIMARY KEY (workout_id)

CREATE TABLE sessions_pushups (
   started     datetime,
   workout_id  int,
   number      int,
   PRIMARY KEY (started, workout_id),
   FOREIGN KEY (workout_id) REFERENCES workouts (workout_id)

CREATE TABLE sessions_rope_jumping (
   started          datetime,
   workout_id       int,
   duration_minutes int,
   PRIMARY KEY (started, workout_id),
   FOREIGN KEY (workout_id) REFERENCES workouts (workout_id)

CREATE TABLE sessions_swimming (
   started    datetime,
   workout_id int,
   meters     int,
   PRIMARY KEY (started, workout_id),
   FOREIGN KEY (workout_id) REFERENCES workouts (workout_id)

This allows you to have complex workouts that do not follow the schema of previous workouts. You could have something like this very easily:

CREATE TABLE sessions_triathlon (
   started            datetime,
   workout_id         int,
   swimming_meters    int,
   cycling_meters     int,
   running_meters     int,
   duration_minutes   int,
   PRIMARY KEY (started, workout_id),
   FOREIGN KEY (workout_id) REFERENCES workouts (workout_id)

Martin Fowler calls the above model "Concrete Table Inheritance" in his Patterns of Enterprise Application Architecture book. Bill Karwin also describes this model in his SQL Antipattens book, in the Entity-Attribute-Value chapter. He also describes the disadvantages in choosing an EAV model to tackle such a scenario.

On the other hand, if you want total schema flexibility, you could consider other NoSQL solutions instead of MySQL. These data stores do not not normally require fixed table schemas.

I'm looking book/online resources about Java EE application deployment pattens. Especially I want to know patterns when to use local interfaces when remote ones (how many nodes I need to?). The key question is to use single EAR (EJB and WAR) or separate nodes for EJB and WARs.

Resources I've found are bitty outdated, they concentrate on EJB2 or design patterns. I'm interested into new technologies like EJB3, Spring or Seam.

I'm studying business layer and need a complete reference which covers issues about "how to manage dependency between business layer and other layers", "how many ways are there to send data between layers" and most important for me "how to group business logic and make business component and talk about possible ways....".

do you know any reference?

EDIT: I would be delighted if you introduce some e-book for it.

Thank you

I think you should consider reading these books.

alt text

alt text

I'm trying to learn how to make my application has the same "face" in all files, the same pattern, but I do not know if this is the right thing to do.

I want know if the more correct in software development, is to limit the application to only one type of pattern.

For example, that's how my application looks like (just a piece)


'use strict'
var Server = require('./server');
var Api = {
 init: function() {


'use strict'
var Server = {
 init: function(command) {
  this.command = command;

  if (command === 'start') {

I'm using the "initializer object pattern" in all my application. So i'm avoiding decorator pattern, facade, everything.

Should i avoid or i can use more than one? If the right answer is use several, depending on the needs, i have other question. This doesn't make the maintenance more difficult? Is not make the code like a spaghetti?



I'm going to try explain again, this time with a bounty.

i already try to ask but seems that no one really can give me a concise answer.

I would like to know what are the secrets from making a good app, a good web app, talking about code appearance. I want know if I should maintain the same standard code throughout my hole application, if this is GOOD, or really doesn't matter.

For example, i have two EXAMPLES files


var server = require('./server');

var app = {
 init: function() {

module.exports = app;


var server = {
 init: function(env) {
  if (env === 'DEVELOPMENT') {
    // CODE
  } else {
    // CODE

module.exports = server;

In this case, i'm using one object with method init, which is the pattern that i'm using in my hole app..

Or it doesn't matter, i should write anything:

first object:

var server = require('./server');

var app = {
 init: function() {

module.exports = app;

than server as a function:

var server =function(env) {
  if (env === 'DEVELOPMENT') {
    // CODE
  } else {
    // CODE

module.exports = server;

I can give 100 of my points. it's incredible how i can't find a good answer for this particular issue.


Should I using other patterns?

No, you should not insist on a single pattern.

No design pattern books will ever advise you to use a single pattern. Just like you cannot chop all ingredients in one single way (are you going to dice the spaghetti?), you cannot organise all logic in one single pattern.

Sure, you can make all your Objects use the initialiser pattern, and don't use constructors at all. This is ok. Been there, done that. I like it.

But these objects can be used with Builder or Abstract Factory (if it make things simpler). As long as the builders/factories themselves have initialiser, and that they properly initialise the created objects, then your use of the initialiser pattern will be consistent. Outside of creational patterns, it is usually good to organise objects with structural and behavioural patterns. They do not conflict with initialiser at all.

For example, look at DOM. All nodes are created by the Document object - elements, text nodes, comments, even events. This is the Factory pattern.

Yet the Document object is also a Facade! From it you access the whole system's status, objects, data, you can even write to it! Every DOM operation starts from the Document, it is the Facade of the DOM system.

DOM nodes also implements multiple patterns. They are organised in Composite, let you listen to events with Observer and Command, and handle events in a Chain of Responsibility. They are certainly parsed by an Interpreter, DocumentFragment is a Proxy, svg elements are implemented as Decorators, and createNodeIterator obviously gives you an Iterator.

The point is, good object-oriented design will yield multiple design patterns as a result, intentional or not.

What are the secrets for good code appearance

I think the best looking code is the one that is easiest to understand to you, and the way you read code changes as you gain more experience.

For example my style is too condensed for most programmers, but to me it strikes a good balance. So do develop your own style - you are not me, and you are not yesterday's you either.

Remember this as we go through the styles.

At the lowest level we have coding style - most importantly indent and bracket.

This one is simple, pick the one you like and stick with it. There are language specific styles, and they are often good starting points. Configure your IDE's formatter so that you can format all your code with hotkey.

Above the code syntax we have comment style and naming convention.

Setting rules on comment is fine, sometimes it is necessary for documenting tools. Avoid too much comment in practice. You may also want to decide your namespace and your stand on naming function expressions.

Above these structures, we have logic conventions.

The same code logic can often be done in many ways, some more 'beautiful' than the others in your eyes. Look at this example.

I picked the second style on first sight: no duplicate, logic is sectioned cleanly, format is not my style but reasonable. But many programmers would prefer the first style: logic is plain as day, a few duplications is worth it. While abstract, this level is quite deep - present your logic the wrong way actually increase the chance an experienced programmer read it wrong.

Finally, we arrives at the level of design pattern, about as far as code beauty goes.

The key to keep your code structure beautiful, is using the right patterns at right level to consistently accomplish loose coupling and code reuse, while avoiding pitfalls and over-design.

There are quite some books about beautiful code, and then there are even more books about designing and implementing beautiful software. (Decide for yourself which are beyond your level.) Knowledge is as important as experience, and you can gain them only by spending your time to study, to write, and to revise/refactor your apps.

Feel free to change your mind as you explore and experiment with your code. Changing your mind is a good sign of learning.

But first, familiarise yourself with design patterns. Just don't forget, they are the generic result of applying object-oriented principals to common tasks. It is still up to you to do the design.

Design Patterns Are Not Silver Bullets.

I'm writing a simple java application (in study purpose) to manage employees and I need an advise: how to store and retrieve data from the database.

Code, that I have wrote so far is too big to put it here, so, in two words:

I have next hierarchy: abstract class Employee: 4 attributes, getters, setters class Salaried: 2 new attribute class Hourly : 2 new attributes class Director: 3 new attributes class Manager : 1 new attribute

I have a MySQL data with 1 table (create script):

CREATE TABLE `employee` (
  `FirstName` varchar(20) NOT NULL,
  `LastName` varchar(20) NOT NULL,
  `Department` varchar(20) NOT NULL,
  `Salary` float(10) NULL,
  `OvertimeHours` float(10) NULL,
  `HourlyWage` float(10) NULL,
  `NumberHours` float(10) NULL,
  `Organization` varchar(30) NULL,
  `Bonus` float(10) NULL

First 4 fields are general for all employees.

Salary and OvertimeHours are attributes of the Salaried class

HourlyWage and NumberHours are attributes of the Hourly class

Salary, Bonus and Organization are attributes of the Director class

Salary also is a attribute of the Manager class

I've created a static class Database to work with the MySQL.

import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.Connection;

public abstract class Database {
    // constants
    private static final String DRIVER = "com.mysql.jdbc.Driver";
    private static final String DBNAME = "records";
    private static final String DBUSER = "root";
    private static final String DBPASS = "";
    private static final String CONURL = "jdbc:mysql://localhost/" + DBNAME;

    // class attributes
    private static Connection connection = null;

    public static boolean fillEmployee(Employee emp, int ssn)
        try {
            PreparedStatement stm = connection.prepareStatement(
                "SELECT FirstName, LastName, Department "
              + "FROM employee "
              + "WHERE SSN = ?"

            stm.setInt(1, ssn);

            ResultSet rs = stm.executeQuery();

                return false;



        } catch (Exception e) {
        return true;

    public static boolean deleteEmployee(int ssn){
        try {
            PreparedStatement stm = connection.prepareStatement(
                "DELETE "
              + "FROM employee "
              + "WHERE SSN = ?"

            stm.setInt(1, ssn);
            return (stm.executeUpdate() == 1);

        } catch (Exception e) {
        return false;

    // class methods
    public static Salaried getSalariedEmployee(int ssn){
        Salaried employee = new Salaried();
        try {

            if(!fillEmployee(employee, ssn))
                return null;

            PreparedStatement stm = connection.prepareStatement(
                "SELECT Salary, OvertimeHours "
              + "FROM employee "
              + "WHERE SSN = ?"

            stm.setInt(1, ssn);
            ResultSet rs = stm.executeQuery();



        } catch (Exception e) {
        return employee;

    public static void createConnection() {
        if (connection !=  null) 

        try {

            connection = DriverManager.getConnection(CONURL, DBUSER, DBPASS);

        } catch (Exception e) {



    public static void closeConnection(){
        if (connection == null) 


            connection = null;

        } catch (Exception e) {



What are you thinking about getSalariedEmployee and fillEmployee methods? How can I improve the overall design and architecture of my application?

Perhaps you should start with a good reading of the book Patterns of Enterprise Architecture. It has a good chapter covering the different ways in which we typically deal with the database.

You can read quick definitions of these in the companion web site:

All the patterns have advantages and disadvantages and some of them have entire frameworks that help you write code for them.

is there any new design patterns available other than the patterns covered by GoF book and Head First Design Patterns? Have any one of you used your own design patterns in your projects? Please let me know. if possible give some UML Diagrams. Thanks in advance.

The "sequel" to the GoF book is Pattern Hatching by John Vlissides. It does not publish really new patterns, but variations of some included in the original GoF book. Its great value is rather in that it shows the thought and design process involved in applying the patterns.

Although this is not an answer to your question in the strict sense, there are also lots of other kinds of patterns relevant to our field:

I was programming for a while. Starting at school, writing small utility programs as a hobby and now professionally. My problem is I'm getting distracted while writing software (I come up with a new feature and fallow it immediately) so my code is usually disorganized. Now when I’m starting my career as a professional developer I find out that even though my software works pretty well the code doesn’t look pretty. I often find myself creating to many or to little classes – sometimes it just doesn’t feel right. Overall I’m losing precious time when I could earn money doing another project.

I’m looking for a book that will teach me how to design software structure without juggling the code in the middle of the creation process.

If you're looking for Design Patterns, there are two authoritative books to look at:

Head First Design Patterns

alt text

Design Patterns: Elements of Reusable Object-Oriented Software

alt text

I would like to know how I can go about implementing my own version of a MVC framework in ASP.NET? I know there already is Microsoft provided ASP.NET MVC framework, but I want to learn MVC and thought the best way would be to implement my own flavor of a MVC framework on top of ASP.NET. Any thoughts / guidance ?

Also, can anyone point me to a page where I can learn more about how microsoft implemented ASP.NET MVC ? I'm more interested in learning about the under the hood plumbing that goes on to implement the framework on top of, do they use HttpHandlers / HttpModules ?


MVC is an architectural pattern that is not dependent on ASP.NET or any framework.

I would not advise trying to implement it on top of ASP.NET if you are just looking to learn about the Model View Controller pattern. ASP.NET will impose too many implementation details when you should instead be concentrating on the overall concept such as separation of concerns, single responsibility.

The ASP.NET MVC framework is simply an implementation of the Model View Controller pattern that runs on top of ASP.NET. Like most implementations it contains variations on the basic MVC pattern to better suit web applications and the underlying framework. So trying to re-implement ASP.NET MVC will give you a non-standard understanding of the pattern.

Martin Fowler explains the fundamental ideas of MVC in the book: Patterns of Enterprise Application Architecture.

Optional assignment for one of my classes. 30-45 minute presentation/case study on either of these two topics:

  1. Examples of currently existing design patterns in real life projects: what problem they solve, why are they better than other techniques, etc
  2. New design patterns, what problems they solve that other design patterns can't, etc

Note that "new" and "existing" are with respect to the GoF book and the design patterns listed within.

For the first one, source code is not required, but it's probably a plus, so an open source project would be the best.

For the second, I'd basically need to be able to give a description like the ones in the GoF book for each pattern, with proper motivations, examples, and the like.

Anyone got some good ideas/pointers?

Rather a simple question. But the implications are vast.

Over the last few weeks I've been reading a lot of material about n-tier architecture and it's implementation in the .NET world. The problem is I couldn't find a relevant sample for Winforms with Linq (linq is the way to go for BLL right?).

How did you guys manage to grasp the n-tier concept? Books, articles, relevant samples etc.

UPDATE: I kind of wanted a sample app not just theory. I like to get into the specific implementation and then iterate the principles myself.

It isn't technology specific but this is a very good book about n-tier architecture: Patterns of Enterprise Application Architecture

Software engineering is concerned with optimising the quality of software projects and the software systems the produce. The process of engineering a software system has many phases and software engineering is the discipline concerned with the whole life-cycle. The life-cycle includes these and potentially other phases:

  • Requirements Engineering: The requirements of the client and other stakeholders are elicited and (usually) documented to provide an specification of what the software should do (and not do). Ideally, requirements are managed throughout the life-cycle to account for change.
  • Design, Architecture and Implementation (Development): Developers decide on high-level architecture and more detailed design to address the challenges of the problem space. The design is implemented in code it using various technologies tools and computer languages; the selection of which is often constrained by stakeholders.
  • Verification & Validation (Quality Control): In this important phase, a high level software validation activity occurs, much of it on a near-complete version of the software system. Testing has become a very important part of software development due to Kent Beck's approach of Test Driven Development
  • Maintenance, Support and Configuration Management: Software needs to be maintained, sometimes to add new features or improve existing ones but often to manage a decaying or unstable execution environment. Configuration management is the practice of managing versions and managing the different components of the software.

Many different scientist have brought many new ways to practice software engineering, like design patterns, and many new approaches to create more robust and powerful software. There is much required reading in the field of design patterns, but the most important texts are:

One of this time's more important software analysts/engineer/architect is Martin Fowler, so his collection of books and bliki are mandatory readings as well.

Another approach is Aspect Oriented software development which looks to separate the program's functions from the Actual business logic.

The subject line says it all. Googling DAL & DAO returns only C# .NET related results.
Is there a DAL/DAO equivalent pattern in the Java world? Are there any reference implementations available?

Of course it applies to Java as well: Don't Repeat The DAO!

Have a look at Fowler's Patterns of Enterprise Application Architecture. Core J2EE Patterns also refers to DAO.

It'd be interesting to check the dates on your C#/.NET references. I'd bet that the idea started on the Java side and was adopted later by .NET. Microsoft probably had another persistence technology that was their "best practice". If I recall correctly, VB used to tie UI elements closely to columns, without an intermediate layer in-between to separate the view from the database.

Where can I find a good high-level overview of Enterprise technology concepts and how they intermingle?

Such as, what is a:

  • Service Bus
  • Application Server
  • Messages
  • Middleware

The book Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions by Hohpe and Woolf, along with its supporting web site are terrific resources.

In the same series, Patterns of Enterprise Application Architecture by Martin Fowler is also very valuable. Martin Fowler's website contains a great amount of material, here is a good starting place:

SOA Design Patterns by Thomas Erl, and the companion web site,, is even more encyclopedic. I particularly like this treatment of the enterprise service bus pattern and its constituent patterns.

As with all books on patterns, once you've read through the introductory material, they can be used a reference books, allowing you to selectively read the topics that are of interest, and perhaps going back later for a more thorough, cover-to-cover reading.

Which is the best tutorial to understand java design patterns? I am not new to java programming, so basics of java need not be required.

you may find these useful :

(but the last two are a bit advanced)

Joshua bloch's book Effective Java is useful even thought its not about design patterns but it's a must read.

You must read Head First Design Pattern.

Though not specific to Java, I seriously recommend you to go for, Design Patterns by Gamma, et al (a.k.a. the Gang of Four, or simply, GoF)

If you are not new to programming you have probably already used a lot of them without realizing it. Design patterns are not language specific, try not to think of them as 'Java' patterns or 'Python' patterns etc. A really good book is Design Patterns: Elements of Reusable Object-Oriented Software.

I am a college student and I'm learning about software patterns (specifically the ones mentioned in the GoF book). I have never been that good at software design, but I'm learning how each pattern works and solves different problems to produce more flexible software. I have a question that has been bugging me.

What's the best way to look at a problem (a piece of software that needs to be written) and determine how to organize it and apply patterns? I recently had a group Java project that went really sour because our design just wasn't very flexible. I honestly just had a great deal of trouble trying to break down the problem into manageable pieces to sort out. I know I can write code, but I don't know how to organize it.

The patterns I have gone through currently are Composite, Builder, Adapter, Proxy, Observer, State, Strategy, Template Method, and Iterator. Like I have mentioned, I know what they are supposed to solve, but I feel like I am trying to force patterns into place. Any help or links to pages would be greatly appreciated. Thank you all!

Patterns are not only a programming tool but also a communication one as well. When there are tens or hundreds of thousands lines of code you need to be able to find your way round, visualise parts and be able to talk to fellow developers about the code effectively. Patterns do this.

The GOF patterns are a good starting point to learn about them but you need to apply them to a situation, not create a situation to use them.

When you get better at applying patterns to the right situation start expanding your knowledge on enterprise patterns and start to see how patterns can be connected together. The latter will start to emerge the pattern of application architecture.

Trust me it can take a long time and experience to get good at them and knowing when to apply them. Just be patient and be curious at the same time.

I'm comfing from the .net world, and want a book that goes over the 'right' way of coding.

Things like dependancy injection, loosely coupling of objects, how to layout your web application properly, unit-testing etc.

Three books that are language-agnostic, but are considered 'classics':

Desing Patterns (by GoF)

Code complete (by Steve McConnell)

Patterns of Enterprise Application Architecture (by Martin Fowler)

Important: don't read them like belles-lettres - read parts of them while practicing.

I am trying to get my head around the common patterns for database abstraction.

So far I've found:

  1. Database Layer
    • just a separate class which holds the SQL
    • does not conform to any other rules
  2. Data Access Object (DAO)
    • like above but there is a transfer object which represents the columns of the database table
    • create, delete, update methods take the filled transfer object as input
    • the find methods may take an input like string (findByName) or an integer (findByAge) but always return lists of transfer objects
  3. Repository
    • abstraction of a collection of objects
    • closer to the domain model
    • I need to read more here
  4. Object Relational Mapper
    • tool which gives me an object which is mapped to the database table in the background
    • the object represents a row in the table
    • a property change of the object leads to an update

Please don't worry too much about my quick explanations of the patterns. I am still in an understanding phase.

But is this list complete or are there other concepts which are missing here?

Martin Fowler's "Patterns of Enterprise Application Architecture" is an excellent book, well respected in the community, which documents about fifty design patterns, around half of which are concerned with interacting with databases. It includes Repository, several kinds of DAOs (more or less covering your Database Layer and DAO) and several entire categories of patterns found in object-relational mappers. So there's a good place to start.

It's hard to summarize any more of the content of POEAA in this answer without simply repeating the list of patterns. Fortunately the list can be found at Fowler's web site. Unfortunately the copyright symbol there suggests that I shouldn't just include it here.

I like Active Record but many say it's bad in performance compared to Hibernate. There should be some good article out there but google can't help me.

If what you want is to compare Active Record (Rails) and Data Mapper (Hibernate), the 'Data Source Architectural Patterns' chapter from Patterns of Enterprise Application Architecture is a good place to start.

It explains clearly the concepts behind these patterns and when to use each one, but doesn't discuss specific implementations like Rails or Hibernate.

I am trying to find a book which contains information and best practices in software development and design. More specifically I need a book which talks about how each layer talks to other layers, for example how the logic layer of the server talks to the data access layer and vise versa, or what information should the client application send to the server and how to do this.

Mainly I would like it to be for Java development but it doesn't really matter.

Code Complete

written by Steve McConnell. I think it will be helpful.

Realated tags