This book should have been entitled "Design of Enterprise Systems with emphasis on Stored Procedures". It really has little to do with VisualBasic or .NET, and more to do with proper large application design in the OO/SQL era.

The author is obviously obsessed with Stored Procedures and makes a very good case for using them. In his systems, every application deals only with stored procedures and never performs SQL statements directly. Well, that's one way of doing it, but it introduces a whole lot of problems that were never really discussed too clearly.

The book is an excellent resource not just for the theory but for practical code snippets you can [take] and use in your next huge, huge enterprise application.

I say "huge, huge", because the sheer amount of overhead you will create in developing any applications based on this architecture is astounding. For anyone who started programming in COBOL, welcome to the world of Microsoft object-oriented programming! You will be spending 90% of your time worrying about coding things that have absolutely nothing to do with the application! Do we really want our application subject matter experts to have to worry about Shared Properties Managers, Object Construction, Threads, Object Pooling? Well, we have no choice if we go with .NET under Microsoft.

If you've stepped away from VisualBasic for a couple of years, welcome back to the new world of Microsoft's vision for a single language with many names. They call it VisualBasic now, but it's just C wearing a mask. Forget about rapid coding. Forget about type-independence. Forget about functions and subroutines. You're going to be spending most of your time memorizing the wall chart of COM objects and trying to learn yet another incarnation of VB that is as incompatible with the previous version as Java is with Fortran.

Don't believe me? OK, use Visual Studio.NET to write a simple application that looks up a record in a table and says "Hello World".

But I digress. The book's treatment of error handling, trace logging, concurrency locking, and other oft-neglected issues is very good and gives practical advice on how to do it. I will personally implement many of his suggestions. Many others I will pare down into a more manageable architecture for a company that does not have a multi-million dollar IPO worth of cash to burn through in the next 12 months.

His critical analysis at the end of each chapter of the proposal presented in that chapter, on the basis of performance, scalability, portability, maintainability, reusability, testability, debuggability, interoperability, and other "ities" was very clever. I will use that, as well as "codability", "readability", "longevity", and "learning curve" to help evaluate what language I want to use in my next application. It might show an MS OO language to be the worst choice. Who knows?

2 pet peeves:

1. "Preventive" is the correct word. There is no such thing as "Preventative", because we do not preventate things. Wonder how that slipped past the spell checker that SURELY every writer nowadays has.

2. "Errand" is running to the store to get something. "Errant" is something that has gone wrong. The entire sample application is built on a misuse of the word "Errand". But I forgive Jimmy because he is Swedish, and if I had to write a technical book in any of my 2nd languages, I would be hard pressed to get absolutely everything right.

Good job, Jimmy.

This book should have been entitled "Design of Enterprise Systems with emphasis on Stored Procedures". It really has little to do with VisualBasic or .NET, and more to do with proper large application design in the OO/SQL era.

The author is obviously obsessed with Stored Procedures and makes a very good case for using them. In his systems, every application deals only with stored procedures and never performs SQL statements directly. Well, that's one way of doing it, but it introduces a whole lot of problems that were never really discussed too clearly.

The book is an excellent resource not just for the theory but for practical code snippets you can [take] and use in your next huge, huge enterprise application.

I say "huge, huge", because the sheer amount of overhead you will create in developing any applications based on this architecture is astounding. For anyone who started programming in COBOL, welcome to the world of Microsoft object-oriented programming! You will be spending 90% of your time worrying about coding things that have absolutely nothing to do with the application! Do we really want our application subject matter experts to have to worry about Shared Properties Managers, Object Construction, Threads, Object Pooling? Well, we have no choice if we go with .NET under Microsoft.

If you've stepped away from VisualBasic for a couple of years, welcome back to the new world of Microsoft's vision for a single language with many names. They call it VisualBasic now, but it's just C wearing a mask. Forget about rapid coding. Forget about type-independence. Forget about functions and subroutines. You're going to be spending most of your time memorizing the wall chart of COM objects and trying to learn yet another incarnation of VB that is as incompatible with the previous version as Java is with Fortran.

Don't believe me? OK, use Visual Studio.NET to write a simple application that looks up a record in a table and says "Hello World".

But I digress. The book's treatment of error handling, trace logging, concurrency locking, and other oft-neglected issues is very good and gives practical advice on how to do it. I will personally implement many of his suggestions. Many others I will pare down into a more manageable architecture for a company that does not have a multi-million dollar IPO worth of cash to burn through in the next 12 months.

His critical analysis at the end of each chapter of the proposal presented in that chapter, on the basis of performance, scalability, portability, maintainability, reusability, testability, debuggability, interoperability, and other "ities" was very clever. I will use that, as well as "codability", "readability", "longevity", and "learning curve" to help evaluate what language I want to use in my next application. It might show an MS OO language to be the worst choice. Who knows?

2 pet peeves:

1. "Preventive" is the correct word. There is no such thing as "Preventative", because we do not preventate things. Wonder how that slipped past the spell checker that SURELY every writer nowadays has.

2. "Errand" is running to the store to get something. "Errant" is something that has gone wrong. The entire sample application is built on a misuse of the word "Errand". But I forgive Jimmy because he is Swedish, and if I had to write a technical book in any of my 2nd languages, I would be hard pressed to get absolutely everything right.

Good job, Jimmy.

If you are looking for a book that gives you a blueprint for building a scalable enterprise database application using the .NET framework and SQL Server 2000 then this book hands it to you on a plate.

Don't buy this book if you are looking to learn Visual Basic .NET or SQL Server because this one is all about applying those basic skills taught in other books to produce a "real" application.

Most books on this subject fit the 80:20 rule, they take you 80% of the way and then ask you to just finish things off yourself. Anyone who is familiar with the 80:20 rule knows that the remaining 20% needed for completion is as much effort again as the first 80%.

This one introduces, designs and builds a real application to completion, consisting of n-Tier architecture with full transaction control, business rules and data access with concurrency control. It doesn't ignore real world requirements such as performance, debugging and testing.

The author imparts tips and tricks learned over the years and gives you a working example of one of the most important design patterns in database access, "Batch Command" (sometimes referred to as "Unit of Work"). This pattern minimises multiple trips to the database by compiling separate SQL statements into a single script that is send and executed in a single call. All code examples are in VB.NET and are accompanied by UML diagrams where appropriate.

In summary this book fits hand in hand with Microsoft's .NET data access strategy and basically hands you the design, implementation notes and source code of a working, scalable, enterprise class application on a plate.

Well worth it!

Some good material in this book that are related to N-tier design, but not a .Net book at all. Less than %20 of the book had anything to do with .Net. It looks like the book was written 2 years ago and then .Net was added to the title to better market the book. I had to return mine.

This is a good book. It is definitely more of a design book than a programming book (as the title says). A good developer has books like this in his or her library though.

Unfortunately, Jimmy's writing is very hard to follow at times. English may be his second language, and it shows. Next time get a better editor -- a very poor job of editing the book was done. Some sentences just run on forever and use a bunch of unneccesary words. This may sound picky, but this type of book is read through entirely and it should be better written and organized.

I do really like how Jimmy expores different design possibilites. He gives the pros and cons of each option, including the one he proposes. He obviously understands the technologies very well and has much real-world experience. You can tell he is an experienced developer.

So remember, this is an enterprise design book. If you follow his proposal you will have an application with many layers/tiers that also makes use of COM+ / component services. For smaller applications this type of design is usually overkill. But for very large applications a good design is critical.

Good book.

This is a good book. It is definitely more of a design book than a programming book (as the title says). A good developer has books like this in his or her library though.

Unfortunately, Jimmy's writing is very hard to follow at times. English may be his second language, and it shows. Next time get a better editor -- a very poor job of editing the book was done. Some sentences just run on forever and use a bunch of unneccesary words. This may sound picky, but this type of book is read through entirely and it should be better written and organized.

I do really like how Jimmy expores different design possibilites. He gives the pros and cons of each option, including the one he proposes. He obviously understands the technologies very well and has much real-world experience. You can tell he is an experienced developer.

So remember, this is an enterprise design book. If you follow his proposal you will have an application with many layers/tiers that also makes use of COM+ / component services. For smaller applications this type of design is usually overkill. But for very large applications a good design is critical.

Good book.

The book is very much a hand's-on architect's/programmer's book. Not much emphasis on an academic viewpoint, but more the practical lessons from someone that has learnt from 10 or more years of design/programming. It contains many little insights that come from experience.

It is (thankfully) not another beginner's book. It is set at the enterprise level.

Good detail on testing and debugging. Throughout there is reference to scalability, fault tolerance and performance. I liked the way he introduced the test bed and using the same debugging approach across different layers.

He is quite bold in suggesting the how things will go in the future (best architecture/design approach), offering various options, but admits some may be wrong.

I would like to have seen more test results, I know these will be available with the non-beta code, but to compare methods, it is useful to see comparative details in the book.

It is a good overview of the possible current architectural solutions. He realises there are many solutions to a problem, like life, the answer is a matter of balance and compromise.

Good size book. Easy to read, so it must have been well written!

This book is perfect for the VB developer who is interested in Enterprise programming, which I define as building apps that scale well and have a maximum amount of fault tolerance and are easy to maintain. It doesn't hold your hand with sample code or screenshots. Instead, it provides Jimmy Nillson's insight into how large, real-world programming projects are built. Its very well written, and Jimmy Nillson provides several different solutions to problems in addition to the one he prefers.

It is well worth buying. One caveat is that this book doesn't cover the details of the language such as ADO.net data access, etc. so you'll want a separate book for that. This is actually the strength of the book because you can find all of that information in the helpfiles, whereas the information you'll find in this book won't be easy to find anywhere else.

This book is a must for developers of COM+ applications developed using any .NET language and any database. The ideas discussed within it apply equally to all languages and databases. Some of the code will need to be re-written in order to work on other databases/lanaguages, but this does not negate the fact that the author covers the concepts relevant to developing the business and database tiers of a multi-tier application.

The author covers testing, debugging, error logging, configuration, transactions, business rules, COM+ settings, data access, error handling and concurrency issues. With each of these subjects, he disusses the subject and then suggests a suitable approach to handle the point in question.

The author obviously has a lot of experience in developing COM+ applications, and this book helps with a lot of the important aspects of distributed application design.

I would defintely recommend this book to anyone designing distributed COM+ applications.

There's enough "learn VB.NET" books out there, most of them not too bad, but nobody dares to stick his neck out at this early stage and suggest an "architecture proposal", which makes these books scaled down product manuals (although easier to read).
Jimmy stuck his neck out and suggests do this and don't do that. Some of his suggestions are not totally OO and so on, but the beauty is that you can see these ideas have been tried and tested in real life scenarios.

If you need to design and maintain enterprise apps, this book should be a very valuable companion.

First of all this book is not about learning a new language syntax! The book is also not filled with code listings. Code fragments are just printed if they have added value in the book. The author provides code examples separately (provided with comments). So it is not a book that the fellow below is looking for (a book that teaches him how to contact SQL Server from Visual Basic .NET)

The book is focused on people that want to learn more about building (large scale) enterprise applications using the Microsoft .NET platform. I personally think this book is as well suited for architects as well as more code addicted people.
The author provides guidelines and patterns for developing and designing data centric N-tier enterprise applications using the .NET platform (using ADO.NET, COM+/.NET Component services, VB.NET/C#) and SQL Server (including T-SQL). Some subjects being discussed in this book: where to put business rules, how to implement these business rules, a new data access pattern, concurrency control, transactions etc.
The book also provides guidelines (not just on the end of the book!) for dealing with testing, error handling and preparing for debugging so it has a positive impact on quality as well as productivity.
The author uses VB.NET for coding examples. I personally prefer coding using C#, but I don't find it inconvenient that the code is in VB.NET.
I like the author's way of writing and the structure of the book. I like the way he describes the pros and cons for solutions and the influences on performance, productivity, scalability and extensibility. He also describes his own experiences (not just theory).
The book gives you guidelines (not only how but also why) so you can evaluate for yourself what will be the best solution for your situation (after all, every advantage has a disadvantage).

I found this book very helpful. It is a long time ago I read an ICT related book from beginning to end!

It's a delight to come across book nowadays that's focusing on a complete solution instead of merely decorating a product manual with better sounding sentences and some miniature sample code.

This book is not a Visual Basic .NET or SQL Server 2000 book. Instead, it's a book on how to build N-tier enterprise applications with these products being the main tools. The author takes an academic approach to his discussions, first bringing us proposals, then rounds up the (sometimes lengthy) discussions with an evaluation of proposals and finally a recommendation. I for one like this approach and it comes as no surprise that the author also gives university courses (at least that's what the back cover claims).

The reviewer below complaining that he doesn't find any sample code to copy-and-paste has obviously bought a book that's way over his head and consequently not qualified to review this book at all.

On the contrary, this book isn't intended to give you any quick solutions, tricks or hacks. Instead it's a book for those who are seriously interested in enhancing the methods they use to build large-scale enterprise applications to make them easier to maintain in the long run. It's a book to make you start think!