Centralizing Duplicate Functionality and Data RRS feed

  • General discussion

  • I need your help and advice regarding a design or architecture issue.

    In our organization we have many applications developed in .Net. These applications contain duplicated functionally and data. For example the employee information is exists in the Attendance, HR and Training applications. That means a duplication of functionality and data which make it hard for us to synchronize the employee data between applications and also its waste of efforts and resources.

    These days we are trying to come up with a design that will solve this problem by centralizing the duplicated functionality and making the data in one place to be shared between the existing applications or any new application that will be developed in the future.

    The idea regarding the above example is by making the HR application is the only application allowed to update employee data and other applications can retrieve the employee data by calling a service that will expose some methods for returning the required data to any application.

    If we follow this approach then the Attendance application database for example will have only the employee badge number and the Attendance application will use the service to validate the badge number and also to retrieve whatever information needed regarding that badge number. The problem that will appear on the surface when the HR application changed the badge number in this case the attendance application will not be aware of it.

    A mechanism should be there to notify and make other application that use employee data aware of the changes and be able to update their data too according to the new changes.

    I have spent several days in the search for information through the Internet and especially the Microsoft web site but unfortunately I did not find what satisfied me.

    Please if you can help us will be really appreciated.

    Thank you.

    Wednesday, August 10, 2011 5:02 PM

All replies

  • Sami,

    What type of database is the data stored in?  SQL Server?  If so, does each department have its version of the data in the same database format?  You might be able to utilize SQL Server replication if that's the case. Otherwise the best solution is just to go through the tedious process of getting all the data into one central database repository so each application is working with the same database.   I haven't used the Sync Framework but that might be an option also.  On the client side, there are numerous ways to use Entity Framework to handle issues relating to concurrency and making sure if one application is changing a badge number that the other application will be able to handle making changes to the same employee.   I think in your case Entity Framework will be a good starting point once all the applications share the same database because you ultimately want each application to be using the same data model.  Unfortunately to my knowledge, EF can't be used across databases (for example an Employee entity mapping to multiple databases) so it might limit its use if you are going to have to keep different databases for each app.

    Tom Overton
    Sunday, August 14, 2011 9:55 PM
  • Hi Tom,

    Yes, all of the databases in SQL server 2008. The databases scattered among more than one SQL server database. We are working nowadays to install and configure SQL server 2008 R2 64 bit cluster environment to hold all of the databases in one server.

    Yes, each department has its own version of the data but in deferent format.


    Sunday, August 28, 2011 6:05 PM
  • Hi Sami

    One way to get the badge number issue handled is to work with an internal identity as key between your applications, as described by Martin Fowler as meaningless key in 'Identity Field' pattern. This could be an INT/LONG database identity, a Guid or anything else. If you pass those ids around in your other applications you are safe against any user changes in your HR application. The only thing you need to keep in mind is not to physically delete your shared data. Either move them into a history table or add a isDeleted flag.

    For the EF lack when working with multiple databases (if you work with EF):

    You cannot connect to more than one database with one EF context, but you can use more than one EF context. I use an own DataContext class provided from data access layer. This holds an internal reference to EF and all data are accessed through strong typed repositories like EmployeesRepository in your case. You business-/service-/whatever-layer does not need to know where data come from, it uses functions like GetEmployeesForDepartment(department). If you do so, you can hold multiple, different sub-classes of EF ObjectContext in your DataContext, you could even mix EF contexts with plain ADO.NET and some data services.



    Tuesday, August 30, 2011 5:09 PM