Mar 25, 2015 at 8:25 PM
Edited Mar 25, 2015 at 8: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