Last post May 31, 2011 05:14 PM by atconway
May 31, 2011 02:10 PM|alanckell|LINK
We are developing an increasing number of applications that are all based on a common database and are starting to question how we should be structuring our applications to handle the growth. We started off with 1 database, 1 data layer, a business layer that
queries this and serves stuff up to the web site front end. We then added a set of web services that queried the business layer and fed desktop applications. Since then we have started making some more applications that use the likes of the entity framework,
which query the database, feed a set of WCF services which provide data to Silverlight applications and more desktop applications.
Before knowing it over the years we have now got a single database which serves a host of web services and class libraries and are finding that we are tripping ourselves up when making changes to the database as there are so many places to check still work
before releasing any of them.
We are aiming to, and have gone a fair way down creating unit tests for the business libraries to make sure that what we are expecting to come out of them still does when changes are made, but these test lists are per solution so our build process would have
to run a series of them for us to be completely confident that we haven't messed anything up before release of an application.
I wanted to throw the question out, are we doing the right thing, or is there a better way? I understand that this is quite an open question so am just looking for pointers as to where we should be looking for the answers.
Any advice would be great.
Thanks in advance,
May 31, 2011 02:40 PM|AZMatt|LINK
It sounds like you are going down the right path. This is just one of those things that you have to stay on top of as your applications grow.
Here is a pretty cool product that helps with mocking and unit testing...
May 31, 2011 05:14 PM|atconway|LINK
It is really a tough question to answer because it is so broad and without an intimate knowledge of all of the systems it is hard to say which Architecture to use or if you are doing things properly.
On the brief mention about Unit Testing code, 'Yes' this is always good to do so from that
specific aspect you are on the right path.
You also need to look at the architecture from (2) different aspects: database and software. You could have a solid architecture (pun intended), that scales and maintains well but have that awful single database housing all kinds of homogeneous data that
does not belong together. You could also have the inverse of this situation where the database(s) were well designed by a DBA and have software with a web form and 10,000 lines of code behind directly accessing the database and using raw SQL.
There are certain architectures like the Domain Model that are better suited for larger enterprise systems with complex business logic that based on its design will help be more protected and self-healing from the ever changing world of technologies. Sometimes
the technology you use will dictate the architecture. WebForms? N-layer, MVP, Domain Model, etc. ASP.NET MVC? Well there you have it: MVC.
You really need to analyze this architecture review from different standpoints: core application, services, database, and even infrastructure (hardware capabilities). Each faction will have its own best practices and architectures to be used. It is really
difficult to say there is '1' perfect architecture or design that will be best for your situation. The best thing to do from the software standpoint is to familiarize yourself with material on Object Oriented Programming, Design Patterns, and Architectures.
Combine this with your intimate knowledge of the systems, and you should be able to being making some decisions on which way to go. The book below written by Scott Millet gives a nice look at several architectures and their implementation. However there is
a ton of free documentation on the MSDN, blogs, etc you can read as well.
Professional ASP.NET Design Patterns
Hope this helps!