I have a number of websites and web based applications running on a dedicated web server. The same box currently also runs the database (and this is unlikely to change.)
I have noticed that the requirements I am getting across different projects are often duplicating each other. So, whilst I am quiet I am trying to replan the architecture of the various sites.
Ideally I’d like to extract the duplicate functionality (logins, some of the user reports, error reporting and so on) into a core library, which got me thinking.
If I make a core assembly, adn add it to the bin of each website, then it will communicate with whatever database is in the app config file. But that gives me versioning / maintenance headaches when things change.
I can put this core librar in the GAC, which means I need to regster / unregister it, but all apps can inculde and use it as necessary.
Or the 3rd way I can see of doing this is to use WCF Webservices and add another internal tier to my aps, where they hand off the core work to a seperate set of webservices. the advantage of this is if / when we expand, all the interfaces can stay as a set of webservices, leaving my apps just making http or tcp calls rather than me having to worry about moving bin files or gac’ed assemblies.
Basically I am here to see if anyone has any thoughts / comments / criticisms of either approach, as I’d hate to start going down one road then have to re do it all going the other way, as murphys law states it will go wrong just as we have a major piece of work come in 🙂
I suggest using the library as a reference as you need it(so it resides in the bin of your application).
What if you need a slight change to one of your reports? After you make the changes, do you plan to do regression tests on all existing apps?
Keeping a different copy of the dll allows you to upgrade it as an when necessary.
Make sure you can find out which app is running which version of the dll.
From a maintenance point of view, you do not always want to change what works.
“What can go wrong, will go wrong”, so limit the area where it can go wrong.