Milestones

Stages of development

This lists the development stages that GenericServices has been through, or are planned for the future, starting with the early versions and working forward to the newer versions, or planned versions:

Note that each service is assumed to be created using dependency injection (DI). GenericServices does not rely on DI at all (in fact it doesn't know anything about it), but a lot of effort has been made to make GenericServices simple to use with DI. An explanation of how DI can inject GenericServices into an ASP.NET MVC application can be found here on the SampleMvcWebApp and it its Git code

Milestones list

First valid version (mid June 2014)

This consisted of two Generic typed versions of each command, apart from Delete which is very simple. Taking Update as an example this had:

• UpdateService<TEntity> : This worked with the EF data classes and directly accessed the database
• UpdateService<TEntity,TDto> : This worked through a DTO, i.e. the user interface dealt solely with the DTO and GenericServices, with the help of AutoMapper, converted this from/to the TEntity when reading/writing the database.

This worked well and is the foundation of the code. However it was a bit 'wordly' when writing it out as you would end up with declarations like IUpdateService<Customer,MyCustomerDto>. It also made the dependancy injection slightly more complicated to set up.

Second main version (25th Sept 2014)

This version used some clever code to work out whether the type was a DTO or not and create/call the right generic version of the methods. Also the type was given in the call, not the constructor which meant a simple, non-generic declaration could be used. This has a very small time overhead, but made the services much easier to use, e.g. for our Update service the declaration was now UpdateService.

Improvement based on using the code (See release Beta4-3)

Having started to use the code in more complex situations, and thinking more about Domain-Driven Design (DDD), the signatures of the underlying DTO code was changed. This is because in complex situations you need to override some/all of the DTO methods. The primary changes were:

• Created separate CreateDataFromDtoand UpdateDataFromDto methods as in DDD (and other situations) they need different code with different signatures.
• Changed the names/documentation of the inner DTO methods to show in what commands they were used in. This just makes it easier for the developer to work out what they need to override.

Simplification of Generic Service (see release Beta5-2)

As time goes on then the aim is to make GenericServices easier to use, and make room for other libraries. This release has the following major changes:

• Create a GenericLibsBase project with some of the common items in it. This is because I am developing a range of libraries for Security, Menus, Identity etc (sorry, these are not open-source).
• remove the Action methods so that GenericServices is just about database access. The action methods are about calling business processes and, while similar, they really belong in another library.
• Refactor to make it very database centric, i.e. remove any code that was there for Actions and rename things to better reflect its focus on database methods.

Improvements to Data-Dto mapping (first version out 2014/10/28)

The master branch has these changes in it, with Unit Tests. However it needs a bit of 'real-world' usage in an application I am working on before I will say its stable.

• Some improvements on how DTOs and copied and the inclusion of the very helpful DelegateDecompiler. This should make copying complex classes to DTOs MUCH easier and save having to override DTO methods in many cases.

Release V1.0.0 (2014/12/23)

The testing has gone well and the DelegateDecompiler guys have fixed various bugs. This is the first release of a non-beta version. It is stable and has been tested on a more complex database and come out very well - see this article for more information.

Note: there is likely to be one more big change in the future as I hide some of the complexity. This is explained in the V1.0.0 Release notes