AutoMapper: Ups, Downs, and Implementations – Part 3

I suspect I’m just terribly verbose since AutoMapper, while useful, probably doesn’t need the over 3000 words I’m giving it, but that’s ok. I enjoy getting my thoughts down and solid which makes me more effective. Anyway, this is part three in a series explaining why we needed AutoMapper and how it can be used. Part 1 talked mostly about the need for AutoMapper, the old ways of writing Object-Object mapping code and gave a quick look into the ideal situation for AutoMapper. Part 2 was about basic mapping exceptions and dealt a lot with understanding lambdas.

In this part I plan to deal with the more detailed exceptions in AutoMapper, and I’ll try to get my idea of when to and not to use it in your application. The guys who wrote it freely admit that sometimes it’s more work than it seems worthwhile to get AutoMapper working in your situation so I try to weigh the benefits of various options.

Read the rest of this entry »

AutoMapper: Ups, Downs, and Implementations – Part 2

In my first post, I basically only made it far enough to show the type of situations that AutoMapper is trying to help avoid and to show a couple of examples of how it can work in the ideal situation. Of course the problem is that we never get the ideal. Depending on the complexity of your objects and the variance of your objects between layers AutoMapper might be almost as much (or more) work than the old school right-left mapping code.

I briefly discussed some ups for AutoMapper, but let’s go back over those.
Quick Review: Where AutoMapper is Best

The best all around, real world, place where I’ve found AutoMapper as the most useful is in the situation of the DataAccess layer. I demonstrated (in the first part) that because a DTO is typically a match to the data model; mapping from a DataReader or DataTable where we have our database call result set is perfect and simple. A single line of code and we’ve accomplished something incredibly useful.

Read the rest of this entry »

AutoMapper: Ups, Downs, and Implementations – Part 1

Object mapping is annoying. Often times, really annoying. Lots and lots of left-right code. AutoMapper tries to alleviate some of that pain, and mostly, it does. In .NET a lot of our programming patterns leave you sitting with an object or collection of one type waiting desperately to be made into another. This isn’t about those patterns and the pluses and minuses of them but rather only with the reality of Object mapping that must be dealt with.

Why do you need object-object mapping?

Well for me, I work in n-tier applications. It’s very common for this type of app to have a data objects. Whether it’s maintained by an ORM (wiki: Object Relational Mapping) or by a custom built data access library, data objects are typically pretty close to an exact representation of your data model. Where as your presentation objects might translate the AddressID on your customer dto to an Address object. So in order to accomplish this cleanly you need some kind of mechanism to map your data object to the relative presentation object.

Depending on the complexity of the object this can become really tiresome. Having to load up a large amount of related data, I’ve had mapping methods span 100~ lines of code. It’s not huge I suppose but when you have dozens of objects and 50-100 lines of code each to map it can become really arduous.

Read the rest of this entry »

What’s it worth? – trying to find the true value

I’m useless at fables and stories with a moral or a message. The big problem to me in trying to explain the many levels and facets of what a story has to say, but I’ll give it my best. This story has so many applications but today I’m interested in the idea of value.

There was a young boy who was talking to his mentor. The mentor says, “Hold out your hand.” The mentor then pours a pile of sand into the boys hand. The sand starts to pile and as it does some falls to the ground. The boy watches the sand, unsure of what to do with it as each shake of his muscles lets a little more fall. The mentor says, “Be careful with your sand, it is all that I shall ever give you.” The boy flinches instinctively and tightens his grip. As his hand moves and his hand tightens all that happens is more and more sands falls out. The boy lost and confused releases his attempted grip. He then looks to his mentor and admits, “I cannot control the sand. It will not be held.” “But you are holding it now,” replies the Mentor.

Read the rest of this entry »

Finally learning OOD

Working as a programmer without a computer science degree can lead to a number of surprises, especially when you’re like me and can’t be bothered to sit around reading computer science volumes in your spare time. Recently I was pointed by a coworker to a page about The Principles of Object Oriented Design. Don’t think I took it poorly, I was glad to be given some helpful direction.

Anyway, it was a rather eye opening experience for me. I read the first 5 principles of class design that evening and loved it. One encouraging thing was finding several ideas I knew and practiced without having the words to describe it. Many times though I found that my habits were not very good and my habits had too often been shaped by bad habits I’d experienced in my career. As I read though, the principles described made sense to me in a lot of ways. The only real counter I had to any of them was the idea that they always tended towards abstraction without necessarily having a tangible reason for it., though I still came away realizing that a lot of improvements needed to be made to the code base I develop.

Read the rest of this entry »