Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Java Books Media Programming Software Book Reviews IT Technology

Patterns of Enterprise Application Architecture 94

Posted by timothy from the puzzle-pieces dept.
Duane Gran contributes this review of Patterns of Enterprise Application Architecture, writing "The title of this book is a mouthful and the author, Martin Fowler, confronts headfirst complex topics of concern to software developers and architects. Fowler is a respected figure in software engineering circles, and his latest book is an attempt to codify best practices he learned in the trenches and through peer relationships. Many of the patterns will resonate with experienced developers, but Fowler's talent explaining abstract concepts will afford even the most grizzled reader many 'aha!' moments." Read on for the rest of Duane's review.
Patterns of Enterprise Application Architecture
author Martin Fowler
pages 560
publisher Addison Wesley Professional
rating 10/10
reviewer Duane Gran
ISBN 0321127420
summary Excellent analysis of complex problem solving

The book is honest and upfront about grey areas in addition to (nearly) hard and fast rules. Fifty one patterns are described in an organized fashion, grouped by theme. The first section gives an overall narrative tying together the concepts while the remaining 4/5 of the book is devoted to short chapters on each pattern. In this way the book works well on two levels, as a reference and a tutorial. Code examples are given in Java and C# where most appropriate for the given pattern, however most examples use Java.

Much of the book centers around the task of Object-Relational mapping between the in-memory model of an application and the datastore. There are a surprising number of design choices in enterprise systems and I often found myself nodding in agreement with the logic behind the patterns. After establishing that mixing presentation and domain logic is a mistake worthy of horse-whipping, a plethora of smart alternatives are given.

I found this to be one of the more enlightening books I've read, and place it alongside Effective Java and Design Patterns Explained as canonical books for the Java developer. I'm a fan of the O'Reilly Java series, which excels in the HOW-TO category of books, but I've recently taken to the Addison-Wesley publications, which deal less with the nuts and bolts, and for lack of a better word are more like WHY-TO books.

Aside from being an excellent book, I also liked that it is hardbound and includes a bookmark (simple nylon strap from the binding). This is a fitting presentation for such a quality book.

The only complaint I might have is that sometimes the code examples are a tad brief for my taste. The author is fond of declaring a class as follows:

class ArtistMapper ...

From the UML diagrams provided I was often able to conclude that ArtistMapper extends AbstractMapper or that ArtistMapper implements Mapper, but as I read the examples I yearned for completeness. Two guesses come to mind as for this choice:

  1. The author explains that the code examples are meant to facilitate understanding, not to provide boilerplate code. Fowler's appreciation for the complexity of software systems leads him to caution the reader to implement the examples without careful consideration to the context in which they are deployed. Partial code examples forces the reader to fill the gaps, and in the process may think more critically about it.
  2. There is often more than one way to do things, like abstracting an interface in Java. The choice of extending an Abstract class or implementing an interface implies a subtle, but far-reaching, development choice. Similar to the previous point, I think Fowler may want the reader to choose a concrete class implementation appropriate for his or her application.
On the whole, I really enjoyed the book and would recommend it without hesitation to fellow software developers and architects.

You can purchase Patterns of Enterprise Application Architecture from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Patterns of Enterprise Application Architecture More

Patterns of Enterprise Application Architecture

Comments Filter:

  • Just Started but.... (Score:3, Informative)

    by RobTheJedi ( 547899 ) on Wednesday April 02, 2003 @12:09PM (#5644736)
    I have just started reading this book, but so far I have found it to be very interesting as this is my first venture into the world of patterns. I found his discussion of "Business Ill-logic" very appropriate to most of the systems I have worked on.

  • So. Cal. study group going through this book now (Score:5, Informative)

    by shodson ( 179450 ) on Wednesday April 02, 2003 @12:10PM (#5644738) Homepage
    We have a design patterns study group that meets in Santa Ana twice a month to study this book. If anybody in the SoCal/Orange County area of California wish to join us please visit our website for more information.

    http://groups.yahoo.com/group/ocpatterns/ [yahoo.com]

  • Nylon bookmark? (Score:5, Funny)

    by shodson ( 179450 ) on Wednesday April 02, 2003 @12:13PM (#5644761) Homepage
    BTW, my book didn't come with a nylon bookmark. That would have been useful. My GoF patterns book has a book marker. I think the use of embedded book markers and hard-bound covers are an attempt to represent the book as more cannonical, a biblical tech reference of sorts. Quite a few of the Addison Wesley books seem to follow this model, like GoF, as well as my 3 volume "TCP/IP Ilustrated" books.

  • Review is as brief as the code "samples" (Score:5, Insightful)

    by binaryDigit ( 557647 ) on Wednesday April 02, 2003 @12:14PM (#5644770)
    Hmm, this review lacks meat. The book is about patterns and the reviewer says the author has good ones. Well how about some examples of these patterns, esp one or two that are non trivial (and thus make having a book like this worthwhile). Since this book is obviously geared towards those with a fairly good level of experience/knowledge, that audience would want to see some real meat in the review, vs "it has good stuff, trust me". And no, a book that states "separate presentation and domain logic" does not automatically qualify it as a good book as this is "Programming 101" stuff.

    • Re:Review is as brief as the code "samples" (Score:5, Informative)

      by jackbang ( 572339 ) on Wednesday April 02, 2003 @12:19PM (#5644801)
      Try the book's site for a complete list of patterns, with diagrams and descriptions: http://www.martinfowler.com/eaaCatalog/ [martinfowler.com]
    • Sorry if it seemed a little brief. I was doing the balancing act and figured my summary of a pattern would most definitely do it injustice and bring about dozens of critiques on my summary. ;) That said, I'll give an example of two patterns that I put to practice with good results:
      1. Serialized LOB - If certain data is stored in the database, but it doesn't change often (or when it changes you drop & recreate) it makes sense to store the data as a binary large object or a character large object. I c
      • Okay, these may not be really impressive, but the ideas were fairly new to me

        No that's fine, it was basically what I was asking for. It is more to give me a sense of what "level" the book was truely at. I realize that even with these two examples that you would have gotten a lot of grief from people who would not agree with his conclusions (you know what they say about opinions). Anyway, given your examples I can make a better judgement as to whether or not it's worth my time to investigate further.
  • How does he find time to do all this and appear in Eastenders?
    http://www.bbc.co.uk/eastenders/chara cters/martin_ f_biog.shtml

  • Looks good... (Score:5, Informative)

    by Coz ( 178857 ) on Wednesday April 02, 2003 @12:17PM (#5644783) Homepage Journal
    I bought this last weekend, and it looks good. I'm seeing a lot of patterns I'd noticed, and he's brought up some that I can look back and say "Yeah, we did that - badly...."

    He does a good job talking about the pragmatic decisions that real architects and senior developers make, as opposed to the idealists and purists. The OO purists may want each attribute's "get" to be a separate call (and maybe cause that call to traverse the network), but the Remote Facade builds much more efficient interfaces. I've been building Domain Models and Foreign Key Mappings for years, and calling them by terms close to those.

    One of the things all these Patterns books have done is define a common terminology for concepts we've all known about. For that, if nothing else, we owe Fowler our thanks.

    • Re:Looks good... (Score:5, Informative)

      by iav8c177s ( 604871 ) on Wednesday April 02, 2003 @12:32PM (#5644875)
      That of course is a large part of the justification for design patterns in the first place -- giving us a common language.

      Fowler's book got a Productivity Award at this year's Jolts -- only reason he didn't get the Jolt, IMHO (OK, not so humble, I was one of the judges), is that Bob Martin's book was a little more fun to read and a little more generally applicable. (That one, BTW, is Agile Software Development: Principles, Patterns, and Practices).

      I can highly recommend either book.

  • Martin Fowler Books (Score:5, Informative)

    by under_score ( 65824 ) <mishkin@be[ ]ig.com ['rte' in gap]> on Wednesday April 02, 2003 @12:17PM (#5644789) Homepage

    I am in the process of reading PoEAA - I agree wholeheartedly with the review. As a professional software architect and mentor, I often recommend Fowler's books. Another great one is "Refactoring" which presents a systematic method for improving the design of existing code.

    I have a list of excellent resources [berteig.org] for software developers, architects, project managers, executives, etc.

    • Re:Martin Fowler Books (Score:3, Informative)

      by dsplat ( 73054 )

      Another great one is "Refactoring" which presents a systematic method for improving the design of existing code.

      I have to second your recommendation of Refactoring. I feel the same way about it that I do about Design Patterns. Nearly everything in it is obvious ... while you are reading it. Those two books are references for the details that are easy to forget. Refactoring also builds more complex refactorings upon the base of the simpler ones. As that started to happen partway through the book, I

  • How does it compare (Score:4, Interesting)

    by bmongar ( 230600 ) on Wednesday April 02, 2003 @12:20PM (#5644803)
    My question is how does it compare to the "gang of 4" Design Patterns book (ISBN 0201633612). It is a fairly complete catalog of patterns.
    I did notice that Fowlers book has code examples in Java, but I didn't find that code was important in describing patterns.
    • Different level of patterns. Less discussion of the simpler things like MVC and more on the "enterprise" things like SessionFacade, BusinessDelegate etc. I read the drafts when they were publically available on Mr. Fowler's site and it was all useful stuff.
    • As a follow-up question, I'd be interested in knowing how it compared to something more enterprise-oriented, such as Marinescu's EJB Design Patterns. For those who haven't read this, it provides a good description of about 20 J2EE patterns, such as SessionFacade, BusinessDelegate and others, with (limited) examples of Java code. Is PoEAA more, or less, theoretical than EJB Design Patterns?
      • I can't comment on a comparison to GoF, as I haven't read it yet, but I am starting to read EJB Design Patterns. I would say that PoEAA is a little more theoretical since it doesn't deal with one framework (EJB). Marinescu's book is ideal for specific advice on using EJB.

        Incidentally, before reading Fowler's book I was a proponent of EJB, however he offers some good critiques of EJB in the book.
  • than a 10/10 for an Addison Wesley book? AW is simply the best technical book publisher out there.

  • Typos (Score:5, Informative)

    by glitch_ ( 48803 ) <email@ryanrinaldi.com> on Wednesday April 02, 2003 @12:29PM (#5644862) Homepage Journal
    Maybe I was the only one who noticed it, but the book is riddled with typos and grammatical mistakes that really make the information hard to absorb. Other than that, the book is very good and I recommend it highly.

    • Re:Typos (Score:2, Informative)

      by GiorgioG ( 225675 )
      Just bought this book, so far so good... Here's a link to the Errata [martinfowler.com].

    • Re:Typos (Score:2, Informative)

      by Atacama93 ( 415662 )
      No, you aren't the only one. Unfortunately, there are so many typos (missing words, incorrect words, and even badly misspelled words) that the flow of the book is significantly impaired. I had to reread many sentences just to figure out what he had intended to write.

      Despite the many typos, I think this is an excellent book and I would highly recommend it to anyone architecting or designing enterprise applications.

      His definition of an enterprise application is based more on examples and characteristics tha
    • I didnt notice the typos, but I did find it hard to read in places. All those cricket examples - I hate cricket.

      Also, although I write a lot of server side code, I dont have so many issues with data-binding as he has. This is very much the 'design patterns for enterprise apps that talk to databases', not 'design patterns for high availability server-side applications' in general.

  • The ultimate enterprise pattern (Score:5, Funny)

    by DailyGrind ( 456659 ) on Wednesday April 02, 2003 @12:31PM (#5644870) Homepage
    1) Purchase an enterprise pattern book
    2) Skim it and learn the jargon
    3) Repeat jargon to anyone who will listen until the powers that be put you in charge of a really large project
    4) Keep promising success until 80% of the effort is expanded
    5) Change jobs
    6) Go to 1)

    • Re:Performance improvement (Score:2, Insightful)

      by Anonymous Coward
      Minor performance optimization:

      Since you have already read an enterprise pattern book, you already know the jargon. The optimized last steps are:

      4) Keep promising success until 90% of the effort is expended
      5) change jobs
      6) Go to 3)

      • Re:Performance improvement (Score:1, Insightful)

        by Anonymous Coward
        The key is that, unfortunately, you must keep learning new jargon and thus buy new books.

        So if you stand up now and say: "model-view-controller" no one will give you the time of day.

        The key to jargon is that it must sound compelling but unknown to the audience.
    • no no, for consultants it should be:

      ...

      6) ???
      7) Profit !
      8) Go to 1)

    • The ultimate enterprise pattern

      Your ultimate pattern is both funny and sad, because it is so true in many people's experiences.

      I wonder if this is another reason why so many projects run themselves into the ground in spite of all the warning signs. For a project that experiences leadership turnover 80% of the way through, the money-holders think, "Well, turnover is a risk and costs money and time, so here's more money and time to get back up to speed."

  • The patterns are available at the author's website (Score:5, Informative)

    by Anonymous Coward on Wednesday April 02, 2003 @12:32PM (#5644879)
    http://www.martinfowler.com/eaaCatalog/

  • One common theme... (Score:2, Interesting)

    by jkauzlar ( 596349 )
    among the reviews on Amazon [amazon.com] was that even for an intermediate level web designer, much of the material in this book is not entirely surprising or new. IMHO, I agree with this, but I think the book's contribution is mostly in its catalogue and well-written analysis of EA patterns. The GoF book contained some patterns that seemed almost like magic to me at first, whereas Fowler's patterns are less magic and closer to common sense.

    I would recommend this book to anybody at least for the sake of having a common

  • Why has the word "enterprise" replaced the word "business" when talking about computer software? Is it just buzzword compliance, or does it actually convey more information?

    • Enterprise Application Architecture == Business Software Structure, no?

    • Re:"Enterprise" I'm sick of this word (Score:1, Interesting)

      by Anonymous Coward
      I think that an enterprise system enables multiple applications to work with eachother.

      An "enterpise" system should have an API/message protocol that enables running applications to talk to each other, yet preserve semantics across the organization.

      It's like comparing desktop apps with ERP systems
    • enterprise imkplies a certian size and expected reliability.
      Business software is specific to a task, not the size of the tsck.

      Example:
      A database that can handle 100,000 transactions an hour, with 99.999 up time is 'enterprise' level.

      an application that tells you what is in your warehouse, business software. If that same software was called enterprise, you would expected it to have 99.999 uptime, and track many thousands, if not millions, of pieces of inventory scattered in warehouses around the globe.

      this is why I laugh when Microsoft calls SQLserver 'Enterprse ready'. it is not.
      • this is why I laugh when Microsoft calls SQLserver 'Enterprse ready'. it is not.

        Agreed. However, don't forget that it and most Microsoft software aren't even ready for the small business.

        Think about how many businesses are now trapped by quickly implemented Access databases and Excel macros, for example. They not only get blocked from accessing their own data without Microsoft's helping hand, but they also face annual upgrade dilemmas by Microsoft's marketing and sales departments. Microsoft's strateg
    • Both "enterprise" and "patterns" are current "in" buzzwords. I have requested a better definition of "enterprise" multiple times, but have yet to get anything consistent. "Expensive" is about the closest I can get to a consistent definition :-)

      Looking at some of Fowler's other works, I am fairly convinced that he tends to do in application code what would best (IMO) be done using the database. Many of the OO "patterns" are sort of roll-your-own-database techniques. OO Patterns get especially messy for mult
  • It is sad that Martin had to write this book. Only in our industry would we make it complex to store objects. Why don't the big RDBMS software manufacturers take some of their profits and create a true OODBMS so we don't have to do this crap.
    • good point. do decent object-repositories and half the data binding problems in the book go away. Plus EJB and IBM Global Services consulting revenue getting websphere to work go away as well.

      So why have all OODBMS attempts died. Was it because the world wasnt ready (and are they now), or is it because data in RDBMS have better flexibility of re-use?
      • Reasons I've heard:
        • There is simply too much momentum behind the relational approach. Organizations don't want to pay for another product or train existing DBAs and developers to another datastore.
        • Although persisting objects to an OODB is simple and trivial, trying to make sense of the data isn't so easy. From what I've heard, a lot of the semantics of SQL don't work with an OODB.
        • Some people think that OO languages are a fad or at least the database will outlive the language. Some are wary to bind the
        • yes, I've heard the same. DBAs are their own little power group in many organisations, somehow they are more important than the mere programmers, though IMO any product that needs full time admin & tuning is a failure in TCO terms.

          XML databases may be the answer. Also, JDO will bind to a OODBMS under the cover -your app doesnt care, but the whole thing just works better. Compare that with the entire Enterprise Java Bean persistence story

          • IMO any product that needs full time admin & tuning is a failure in TCO terms.

            Compare this to the use of full-time operators for administration and tuning on mainframes in a recent article: Mainframe Operators Needed [slashdot.org]. The large companies using and buying mainframes would seem to approve of that particular TCO.

            • I guess they do. As do WinNT cluster owners.

              our philosophy on server-apps was 'a box that works so well, you forget where it lives'; I think novell were the first people to pull that off in products.
    • You don't quite get it. One of the first paragraphs in this book is "What differentiates Enterprise applications from all other apps"

      In other words, he basically explains why you can't just "whip up" a web app in perl that will work for a 10,000 user system that uses 5,000 datapoints with some data having 100 different business logic cases between.

      Storing an object may sound like a very black and white thing, but in an enterprise context, it's all about the relationships and the logic and if you don't fol
      • In other words, he basically explains why you can't just "whip up" a web app in perl that will work for a 10,000 user system that uses 5,000 datapoints with some data having 100 different business logic cases between.

        Sure you can. Just tap into a big relational database. That is one of the beautiful things about RDBMS: you can add a new "task" or "micro-app" to it just using relational queries (and maybe some transaction markers). It does not matter whether the DB contains 100 records or 1 billion, you
      • Actually I do get it and I'm a fan of Martin Fowler's books. As a writer of "Enterprise Applications" myself I'm just frustrated that the database manufacturers have not caught up with the programming manufactures. We have powerful OO programming languages but we have to translate objects to rows of data to store in a table! That is so last century.

        Why do we have to make it hard on ourselves, surely creating code in an object oriented programming language and storing the data in an object oriented database

        • We have powerful OO programming languages but we have to translate objects to rows of data to store in a table!

          OO programming languages allow programmers to create vast, ad-hoc conglomerations of data, then hand-write ad-hoc code to traverse, read and manipulate those data structures.

          The relational data model makes the relationships between different data explicit, and exposes those relationships in such a way that other programs can write all the code to traverse, read and manipulate them. This is

    • Re:Great book, sad day (Score:2, Informative)

      by Tablizer ( 95088 )
      Only in our industry would we make it complex to store objects. Why don't the big RDBMS software manufacturers take some of their profits and create a true OODBMS so we don't have to do this crap.

      OODBM's have some serious drawbacks that seem to re-expose the same problems that pre-relational databases had.

      Relational has the concept of "table" that is a higher-level structure than a mere "record". OO lacks a decent higher-level structure than a record (class/object). (Trees and GOF patterns have been tr
      • let's not leave out the greats, thanks to dbdebunk [dbdebunk.com].

        fact of the matter is, relational theory is mathematically sound, complete, etc. sql is not. it is ... a badly designed interface into a much neater world. having a language that let us do with relational data everything we -should- be able to do would be wonderful. the current obsession with sql (and variants) is actually hurting us.

        [snip: rant about wrapping tuple data in objects because it's "cool"]

        i would like a good set of OO principles for database
        • fact of the matter is, relational theory is mathematically sound, complete, etc. sql is not.

          Well, I agree that SQL is not the perfect relational query language, but that is kind of a side topic. Even imperfect relational stuff has some nice benefits.

          (because of specialization / generalization by constraint: is a circle an ellipse, the other way around, or neither?)

          The long-standing circle/ellipse debates are simply another way to say that "abstractions are relative". Inheritence tends to assume the
      • Agreed. The relational model has stood the test of time because of its flexibility. When you start adding methods to data, i.e. create objects, you start to dictate the structure of data. This is good for applications, but not so good for shared data stores. The relational model allows you to store the data in a far more application-neutral manner than you can with OO structures. You can more easily reanimate the data in whatever manner you please (though it may cost you). That means more sharing, ironicall
        • You can more easily reanimate the data in whatever manner you please (though it may cost you).

          What do you mean by the cost?

          You've got pretty much too choices in object-relational mapping: write a custom mapper or suck wind with a framework. Hopefully we'll find some better options soon.

          I am a bit skeptical that relational and OO will ever fully get along. They are just too different in their *root* philosophy. Relational is *tightly* based on the concept of a table, while OO is not. Tables incur ce
          • Joins can cost you a lot, depending on how you slice and dice, yah? And how much normalization. And especially if you have hierarchical data, which the relational model isn't too good at.
            • Joins can cost you a lot

              Are you suggesting roll-your-own joins (not "joints") are faster? Most performance problems with joins can be traced to bad schema design in my observation.

              And especially if you have hierarchical data, which the relational model isn't too good at.

              Well, that is debatable. Most uses of large hierarchies are improper IMO anyhow. Oracle has added hierarchical extensions to SQL, I would note.

  • Sounds like a good strategy re: code (Score:4, Interesting)

    by dmorin ( 25609 ) <dmorin@@@gmail...com> on Wednesday April 02, 2003 @01:20PM (#5645252) Homepage Journal
    I know that the value of printed texts, to me, decreased when we started including CDs with every book (or downloads for every magazine). Why? Because when all you're doing is running somebody else's code, usually without even looking at the source, you never get a chance to internalize it. You never have to say "What's this and why does it do that?" other than to answer "Because that's what the author chose to do and it's supposed to work like that." Back in the old days when you actually had to type code in, every line of the source went from print to eyes to brain to fingers. So whether you knew it or not you got a flow for what was going on. And you saw parts that interested you that you could come back to.

    These days code is so big that this is unfeasible. So it seems like Fowler has chosen an interesting strategy -- give you most of it. That way you still have to get into the editor and experience the source, but you don't have to spend days in order to do it. Nice. Learn by doing at its finest.

    • people who want to internalize will, everybody else is a book buying sheep who wants a nice collection of books to impress there boss.
      You can tell by the bindings, and the amount of yellow stickies poking out of them.
      Except for the K&R book, the standard for use is still the number of coffee rings on the cover. ;)
    • back in the old days? what? in school were "collaborated" on cobol assignments which was little more than borrowing a disk from someone who had the exact same class last term, then makeing sure it still ran. coding languages requires you to understand the concepts and to implement them. if you need to know what a for loop to iterate of a collection looks like, google it or get eclipse ;). if you're memorizing this type of stuff, well you're not spending enough time reading /.

  • Good Stuff (Score:5, Interesting)

    by the-dude-man ( 629634 ) on Wednesday April 02, 2003 @02:09PM (#5645647)
    Books that will rant on at lenght about the technical details about languages like java and c# are a dime a dozen.What is lacking is good books that solidly illustate the patterns behind object oriented design.

    I think the reviews critisim about using such concepts as extending and implemeting in excess is not warrented, the book is about Objected oriented design, there are other ways to implement these methods, however, implementation of interfaces, and extending other classes, is really *the* object oriented way to solve this problem. Its hardly fair to say that its merly one way to solve the problem. There are many ways to implement the concept of extending another class or implementing an interface, however, these are technical details, and the primary focus of the book is patterns, and design principles, and wich ones work, and wich ones dont.

    Also, the other speaks of the lacking of code samples, agian, this is not a codeing book, the focus here is design, and principles. Therefore, code takes a back seat. The problem with putting code in books, is that you get bogged down by implementation details, wich really goes outside of the scope of what the author is talking about, with short code samples, the point can be convayed. How to implement it in a more complex situation in a particular language is the job of the individual devloper. This book obviously isnt going to get into it, because its about design.
    • Too bad I don't have any moderation points for "funny". Good use of typos :)

    • Here's a pattern that doesn't get mentioned enough:

      Cranky old people bitch about how much better things used to be, then they give birth to young people who grow up to be cranky old people who...

  • Great book (Score:2, Interesting)

    by rbgrn ( 443653 )
    I picked this book up last month and read probably 30% of it so far. All I can say is that it is very well done and although I get slightly annoyed that he references other materials without providing more concrete examples, overall the book is very well done and really does provide a good dictionary of patterns as well as comparisons to different patterns with pros and cons for each.

    IMO, this book is a must-have for writing enterprise apps.
  • I am a long-time fan of Fowler's book "Analysis Patterns", it has become a trusty fellow. Can anyone tell me how this book measures up to Analysis Patterns?
  • My only beef with the book is that he didn't go further into why one pattern would be better than another in a given situation. For someone new to patterns, it can be like a chinese buffet with 100 different dishes on it - how to choose from among so many tasty items?

    Of course, every situation is different. But there are common tasks (I won't use the phrase meta-patterns) that programmers do - write a e-commerce shopping site with shopping-cart, deal with nested objects like invoice-lineitem, etc. And

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close