It's been way too long since I've posted here. Yes, I'm still around, and I'll be posting some topics very soon. I've been lucky to receive some great books related to .NET and I'll be posting reviews of each of them shortly.
At work, I've been primarily working in the J2EE world. I've enjoyed most of it but man, I really miss .NET. It sounds stupid but I really enjoy the experience of developing with Visual Studio and the .NET platform.
Stay tuned!
I've had the pleasure over the last few months to perform technical editing for McGraw-Hill on an upcoming ASP.NET 3.5 book aimed towards beginners. This has been my first experience being a part of the process of putting together a book. I really enjoyed doing this kind of work and working with the author in his efforts to bring forth a great book for beginners to learn about ASP.NET, specifically 3.5 material. You can find the pre-order page here on Amazon (
http://www.amazon.com/ASP-NET-3-5-Beginners-William-Sanders/dp/007159194X).
Today I was given the opportunity to act as the technical editor for another project for McGraw-Hill. I'm definitely looking forward to this book and working with the author. This book will likely publish at the end of this year. Of course I'll give more details once that date approaches.
I'm very interested in continuing to perform technical editing for publishing companies. In the future, I'd really enjoy the opportunity to author my own book. Until then, I'll stick with the editing gigs. If you'd like to hire me as a technical editor, please contact me at cstewart913 [AT] gmail.com.
I know it's unrelated to .NET but I'm a Mac person, so I've been really drawn in to the iPhone SDK. Am I the only one from the Microsoft developer community? I've even started up a blog and forum dedicated to the topic:
http://www.iphonedevsdk.com
I've been reading another book from Packt Publishing, called "LINQ Quickly". Again, it's a pretty short book, coming in at 250 pages. The author does a decent job at explaining the basis of LINQ and the various implementations, such as LINQ to SQL, and so on. What would have been a welcome addition to this book is a more practical approach to the technology. Perhaps by building a real application along the way. There is an appendix for just that, but it's a disappointing 7 pages. The book's subtitle mentions it being a practical guide but I didn't see that.
If you want a brief overview of what's possible with LINQ and the various implementations, you'll probably find the same information for free across the web. I was hoping for more of a real-world introduction.
I've been working my way through "ASP.NET 3.5 Unleashed" lately. Although I'm not quite finished, since the book comes in just under 2000 pages, I do feel confident in writing a review.
The Unleashed series has a certain following behind it for being a fairly comprehensive guide to the technology the book examines. This entry into the series is no exception. This book goes into every detail of ASP.NET and ready digs into the new features of 3.5, as you may expect given the title.
I've enjoyed the way this book presents material. It's not too detailed for the beginner but doesn't leave the experienced wanting too much more. I would highly recommend this book to anyone looking for information on ASP.NET 3.5. This book is something every ASP.NET book should aspire to be.
Recently I've been talking about dependency injection and ASP.NET MVC. Each are interesting technologies and are "hot topics" in the ASP.NET world right now. I had decided that my newest project would utilize these, if for nothing else but to learn them in more detail.
I had spent a few days working on the service level code for this project. After building a few dozen interfaces and concrete classes, I felt like I simply had too much unnecessary code. In my situation, which is equivalent to 95% of my past projects, the benefits of dependency injection did not outweigh the tediousness of implementing it. I'm not going to reuse any of the code in my data, business, entity, or services layers. So why spend so much effort and add so much complexity to decouple them? I don't need extra implementations of my interfaces that would effectively be injected into my application. So why implement a framework that is so heavily in favor of that?
The only benefit in my situation was in the unit testing arena. In this case, I really had no plans to unit test this application. I simply don't need it here. Now, I'm sure that's awful and everything should be unit tested, but seriously, it's not always necessary. I know test driven development is the popular thing this year but it's not always advantageous to follow that practice or even unit test to begin with. This application is one of those exceptions. I could explain why but someone will object, so I'll move on. :)
After a few days of sitting on the code I had written and debating my course of action, I decided to pull out the dependency injection and ASP.NET MVC and use plan old Web Forms with a typical n-tier architecture. Everything is tightly-coupled and impossible to unit test from the presentation layer, and I couldn't be happier. :) As a disclaimer, I was only using ASP.NET MVC because of how well dependency injection fits into that programming model. See my previous blog entry for more.
I like dependency injection and I really like the outlook for ASP.NET MVC. What I've learned in the last few weeks is that they have their scenarios where they're more appropriate, and that there are instances where they don't fit. The overhead in creating the code to implement dependency injection is not trivial. Take a hard look at your problem, application, and development environment before deciding which path to take. I have a wonderful application I'd like to tackle that would fit ASP.NET MVC and dependency injection perfectly. It's just not the one I'm working on right now.
It's not that you can't use dependency injection in any .NET application, because you can. It's just that dependency injection fits so well in the ASP.NET MVC programming model. While building up a simple example for how my new application would be architecturally designed, I found using dependency injection with Web Forms as troublesome as trying to fit a square peg into a round hole. After some modifications and adjustments, I could get it to work, but it just didn't feel like a solid fit and certainly didn't make me any more productive.
I decided to give the ASP.NET MVC programming model a try and found the experience much smoother. Not only did everything simply work easier, but you get a sense that the two were meant to be used together. Using the Controller approach found in MVC, it's extremely easy to inject your dependencies using constructor injection.
Designing software while using dependency injection has changed my normal approach. I've found myself creating an extra layer or two of abstractions. The implementation of the classes I'm building is pretty simple and somewhat resembles the Facade pattern. My classes essentially boil down to a small set of service classes that are injected into the Controllers as needed. All of the services that are injected into the Controllers are done so by using interfaces for the service. The concrete implementation of the service classes are actually composite classes. They use the various repository classes (think subsystem) they need to offer up a set of common methods that define the service. I guess it sounds more complicated than it really is, but the idea is that everything is loosely coupled to everything else. Everything is interface driven, so supplying concrete implementations is the job of StructureMap, my dependency injection framework of choice.
I can't say that dependency injection is "the way to go" for every scenario. In fact, my current application doesn't really need it except for maybe one instance. However, what I do like about using dependency injection is the side effect I mentioned above. Using it has me thinking about my n-tier architecture in a different way than before. I've found useful instances of working in an interface driven environment. I also enjoy the approach of creating services for the various subsystems in my framework. It's certainly something you can do without dependency injection and ASP.NET MVC, but it's something I've found very useful in solving business problems while using those technologies.
I decided to go with StructureMap as the dependency injection framework for my next project. I choose StructureMap for a number of reasons.
StructureMap has been around for quite some time. Not that this makes it better than any other framework. However, coupled with the fact that it's an active project, it's still a hot topic in the world of DI for .NET, and a lot of .NET developers use it in their applications, I feel pretty good about it's history and future.
StructureMap 2.0 does not require an XML configuration file. In my opinion, the last thing we need as .NET developers is another XML configuration file. That's what I dislike the most about Java. You can't build a J2EE application without writing a mountain of XML configuration.
Probably less of a feature and more of a convenience to me, is that StructureMap has only one purpose and that's providing a dependency injection framework to .NET developers. Spring.NET is nice and it does a ton of things. That scattered focus left me feeling scattered after creating a sample project using Spring.NET. I'm sure everyone has their own feeling towards this but for me, I felt less interested in Spring.NET after reading and reading about all of the various things that framework can do. I just wanted DI and that can be done in Spring.NET rather easily and separate from everything else the framework provides. It's just information overload while trying to learn the one specific thing I wanted to learn.
So there you have it. I'm excited to get started on this project and dig deeper into StructureMap. I'll certainly provide opinions and lessons learned throughout the process.
I'm in the planning phase of a new ASP.NET project. Currently I'm evaluating the various software components and packages I'm going to use to put this project together. With all of the hype surrounding Dependency Injection, I've decided to give it a try in this new project. The two most popular frameworks for DI, as far as I can tell, are Spring.NET and StructureMap.
I'm leaning towards Spring.NET simply because it offers so much more besides DI. I can, however, appreciate the XML-less features present in StructureMap 2.0. I'm not sure whether that feature is important enough to choose StructureMap over another offering.
I'm hoping the ASP.NET community can lend some advice as to which framework to use. Of all of the available options, which would you choose and why?
I just finished an interesting book, "Managing Software Development with Trac and Subversion". Trac, a ticket management system, and Subversion, a source control management system, are open source software that are very popular in the community. I've used each extensively and really enjoy what each of the solutions bring to the table over their competition.
The author does an excellent job explaining everything you need for getting an environment set up. By the end of this book you'll understand the setup, configuration, and usage of each of these tools, in addition to Apache.
I would highly recommend this book to anyone looking for a free solution to project management and source code management. It's a rather quick read at 120 pages but enjoyable and useful.
More Posts
Next page »