Some questions

Mar 25, 2015 at 9:25 PM
Edited Mar 25, 2015 at 9:28 PM
Taken a look at this project as I was interested on how others layer their Solutions and in turn share the knowledge to my team. I am a Lead Developer of a team of 8 and am always looking out for ways to become better :-).

There are a few things which raised my eyebrows a little on this Solution.

You've used an EDMX file for use with Entity Framework. We discounted the use of EDMX or Model First using EF back in 4.2 - it actually drove us to Fluent nHibernate. You can't guarantee that anytime the model is refreshed, that your code won't regress. Our apps would break whenever a small change was made. We've since moved back to EF6.1.3 and now use the fluent mappings. These are highly testable and work very well with a set of POCOs. Why the use of EDMX in an enterprise solution?

Lack of IOC. There are objects being 'newed' up all over the place here. How do you mock each of these classes for unit testing? Take the LeaveComponent.cs file. It 'news' up a class in nearly every method. I had a look at the tests but, they're Integration tests. How do you mock dependencies?

There are 'Entities' which are used throughout the application. You've split their behaviour (the Validations) out into a separate project. This seems to break the encapsulation. We generally have 3 sets of entities within our applications.
  • POCOs for use with EF. These are a near identical match in data type and name to the SQL table counterparts. This makes the EF fluent mapping code very easy to understand.
  • Business Objects. These contain the same properties as the POCO in addition to calculated fields. Guard clauses and internal validation. These objects tend to contain much of the logic surrounding any type and should always be considered valid.
  • View Models. These mirror the views/forms/webpages closely. They may flatten an object graph down into something the UI can represent.
We tend to use AutoMapper and AutoMapper Profiles (which are testable too) for the translation between these different objects.

I was looking at the WinForms example. I wondered why the MVP pattern (or indeed another suitable pattern) hadn't been applied here.

You can see the LoadLeaves method on the form code behind, which is plumbing code, should not live here with methods which manipulate the controls. The 'LeaveController' class is static and is currently very hard to unit test.

Again, I'm genuinely interested in the design choices here and don't intend to flame or critique :-).

Thanks for sharing this
Aug 5, 2016 at 1:59 AM

The samples were created to illustrate Layered Architecture Pattern and not focused on Design Patterns and O/RM technologies. The reason is because through the development of the samples, I have discovered that it becomes more complicated and confusing to an early adopter if we put more things in it. You have mentioned a lot of design patterns and DDD stuff which was supposed to be covered in another sample published by Microsoft but unfortunately, I think they took that down already.

On a personal note, some of the design patterns do look very cool and can serve as a good academic topic, but they don't really provide good performance. Following the concept of Solution Pattern -> Architecture Pattern -> Design Pattern, you will realized that Architecture Pattern can sometimes solve problems that design patterns tried too hard to solve with code. For example, you can actually take the EF and DAAB version of the samples and literally 'copy' and swap the Entity and DAC dlls and they will still work - There goes all the hard-work we put into that awesome Repository pattern and IoC that we all talked about which not only created complexity but also impacted the application performance.

You are always free to use the base Architecture Pattern and combine it with whatever Design Pattern to make it look awesome provided you are aware of the performance impact.

Best Regards.