The other night I sat down and just paged through it - you know, kinda like getting a feel for the book; layout, topics, content, etc. Took me almost 2 hours to do this! ... So this should give you some idea as to how big this book actually is (~800 pages).
Initial impressions ... Looks good. So lets get started:
1. There are a fair amount of diagrams in the text, which I like. Diagrams tend to give you (the reader) an overall outline of what is going on without too much "blurb". I find you can pick up a lot of information from the picture before having to read any text and as the old adage goes, "a picture is worth a thousand words". Too right mate. (But there's still 800 pages!)
2. There is ample code to scan through which is again, something that I tend to like. The code is clear to read and nicely highlighted for the reader to focus in on.
[Note to self: Must remember to download all the code from the website.]
3. There is a nice 'introduction' (~200+ pages) that runs through "general" topic areas such as frameworks, key technologies, OO, etc. Great stuff and worthy of paying some serious attention to, after which the author moves into the actual business objects and the way that you can interact with them via web forms, desktop forms and web services. Batch processing and reporting is covered at the back end of the book ... Not a favourite subject of mine to be honest and judging from it's position in the book, not the authors either.
Right, well, better make a serious start on doing some reading then.
I estimate that I can probably get through about 50 a week if I run through ALL the code as well. Given the amount of pages, that means it'll probably take me 4 months to complete this book. And then there's the full review to write.
Did I mention this book was not for the faint hearted? :) ... Xmas present anyone?
1. Introduction
Very nice. Simple, straightforward and VERY relevant. The author discusses some of the real issues involved in application 'design': logical/physical/distribution. As he puts it: "The goal of a good physical architecture is to achieve the best trade-off between performance, scalability, security, and fault tolerance within our specific environment". This is an area that I feel a lot of IT personnel continue to overlook - whether by default or 'intention'. Well worth reading.2. Framework
Wow. Another classic. Loads and loads of good advice on framework design, the reasons behind them; pro's and con's to the choices made (here). Will probably take me another read through to FULLY grasp all of the inter-related issues contained therein. But once again, easy to read. No boring, yawn inducing lectures here. These are the kinds of areas that I wished I had had pointed out to me 10 years ago. More time (during development) should most definately be spent examining and relating this kind of information within the entire IT project group. Great stuff!3. Key Technologies
A clear and straightforward examination of some of the .Net technologies that will be used in the rest of the text. The author makes these sometimes 'complicated' technical areas very easy to follow and understand. Some nice "intro" examples are included - which I particularly appreciate, given the overly verbose structure of some of the MS ones. I particularly liked the area's concerned with Enterprise Services (COM+) and remoting. I did however have one minor disagreement: The use of Stored Procedures - "... , this technique automatically quards against SQL injection attacks." Not so; Heres' a parameter driven SP that is vunerable:CREATE PROCEDURE dbo.RunQuery
@var ntext
AS
exec sp_executesql @var
GO
Perhaps the author should have stated "... , the use of parameter driven queries, whether constructed dynamically or within stored procedures, helps to quard against SQL injection attacks, notwithstanding bad programming practices such as the one stated above."
4. Business Framework Implementation
The author runs through the "building" of some of the common concepts wrapped around his earlier framework design. I have to admit that the author does an extremely good job at making it all look soooooooo simple. This probably comes from experience I think and it's another chapter that would inevitably need a second run through - from my own perspective anyway. There are some nice straight-forward diagrams to help explain some of the logic involved - particularly the 'complex' nature of n-level "undo's". This is the first time that I have really read through framework design explanation ... from concept to building. Might be a good idea to create a simpler one of your own first though - perhaps even based on the authors one, in order to appreciate some of the finer details contained therein. Good stuff. Next?! ....5. Data Access & Security
Like most good stories, this chapter runs very nicely, with one section following on very nicely from the next. I did have some very minor gripes with naming convention consistency - but that was very minor! What tends to come across in this chapter, perhaps stronger than in the previous 4 is the 'extensive' use of interfaces to manipulate / utilize the .Net base objects in creating the remaining objects for the framework that the author requires. It really is terrific to follow the process and see / read the code as you progress through the chapter. It reads very well. In fact it reads so well and easily that you begin to wonder what's so difficult about creating frameworks, and I'm not sure if this is a good thing or a bad thing. What I can say is that you learn a lot in the process.6. Object-Orientated Application Design
Object Relational Mapping (ORM) That's what this chapter is all about. Nicely done with the use of a simple "Project" application example. The author runs through the various "use case" business cases to model the application first. The ORM discussion is as interesting as ever, as was a short reference to the lack of transaction control at the stored procedure level - due to the Framework's use of either Enterprise services (COM+) or direct transaction coding in the actual business objects.7. Business Object Implementation
As the singer/rap artist Eminem once sang (Eight Mile) "oops, there goes gravity" ... the first half of this chapter started to loose me. Maybe I was distracted!? Here the author delves into how each "type" of business object (template) utilizes framework objects to accomplish common required business object functionality. To be honest I found this section tough going - but perhaps this is mainly due to my own lack of general framework experience and understanding rather than the actual information being relayed to the reader. However, lets see ...The 2nd half of the chapter concentrates on using the business "templates" previously constructed to create the business objects that the application uses. This section is more 'straightforward'. But, I still had to keep stopping to reflect and flip back to previous sections to establish for myself the "route" that the code was following in carrying out its work. This is both the upside and the downside of OO projects; In that, you need to fully understand exactly what is going on behind the scenes before you can fully appreciate and therefore utilise the underlying objects to their fullest potential. This section then is the culmination of the previous 340 pages (3 chapters) of work. Nicely done I must say but, having said that, I really need to read them ALL again to really understand everything that is going on here; It's good stuff, but a couple of extra diagrams detailing the object route may have helped to clarify the various intricacies of the development rather than pure code.
[It looked like there were some minor code grievances, but I couldn't establish this without running the downloaded code against the book's text. An exercise I'll leave till later I think]
Comments