2

I am trying to follow TDD principles in all my code base. The frontend (MVC) and backend part are split, and frontend use their own Model objects, while backed use database objects which are then saved to a document database (RavenDb).

This requires a lot of conversion from say CustomerModel to CustomerData. These are created independently from each other, so the strucutre might not match. For example, the CustomerModel might be flat while CustomerData has a nested object ContactDetails.

Currently, we are implementing two methods, one say ConvertCustomerModelToCustomerData and ConvertCustomerDataToCustomerModel. These are very similar, but inverse of each other. Apart from this, these methods are also unit-tested. Hence, similar code is created in four instances - twice for each conversion, and twice for each unit test.

This is a big headache to maintain, and does not seem right to me. I've tried to use AutoMapper, however I found it quite rigid. Also, I could not find any way how I can unit-test this.

Any ideas would be greatly appreciated.

Karl Cassar
  • 6,043
  • 10
  • 47
  • 84
  • 2
    Why do you find AutoMapper "rigid"? You can create custom profiles if your POCO properties are not a 1:1 match with the other object. And you don't have to test AutoMapper conversions, this would only test AutoMapper itself (which is probably already well tested). – Pierre-Luc Pineault Sep 24 '14 at 17:13
  • 2
    What do you mean by "rigid"? I've found it to be fairly flexible, if not always well documented. As @Pierre notes, you shouldn't really need to test your mappings, as AutoMapper itself is built with unit tests. What I would recommend doing is calling `Mapper.AssertConfigurationIsValid()` after you set up your mappings ("if you're going to fail, fail early and loud"). – David Sep 24 '14 at 17:16
  • Why do you need separate models? If the relationship between the models is as 1:1 as you imply then why can't the UI simply use the models it gets from the back end? Where does the actual business logic live in this system? – David Sep 24 '14 at 17:17

1 Answers1

0

I think that having well defined boundaries and anti-corruption layers (see this and this) like the one you did is a great way to avoid headache, and bug hunting an highly coupled application is far worse.
Then, these layers are for sure boring to maintain, but I bet that dealing with is is simple, a no-brainer activity.
If you find yourself modifying your entities often (and so having many tests to update), maybe they are not well defined yet, or they have too wide scope. Why do you need to update them? What's the trigger?
Then, AutoMapper can help you a lot, I agree with other comments.
Anyway, without seeing the code it's difficult for me to judge and maybe offer any kind of advice, so feel free to consider this just my humble opinion :)

Ferdinando Santacroce
  • 1,047
  • 3
  • 12
  • 31