What architecture to use? RRS feed

  • Question

  • Hi,

    I work at a small software engineering company. We are facing some issues regarding maintainability and speed with our applications. Currently, we have the following situation:

    For each of our customers, we have developed a custom solution that consists of a single database and multiple applications (sometimes as much as 50). The applications have been developed throughout the years. As a result most of them are written in VB6. Currently we're working with C# / Visual Studio 2010 / SQL Server 2008.

    We are trying to find out what the best possible architecture is for our system. We have been experimenting with a N-tier architecture using a Business layer, Data layer and sometimes a Shared layer. Right now we have a BL and DL for each new application. The data layers use stored procedures to access data on the sql server.

    I've been thinking of creating a single data and business layer for our entire system. All applications could then use these libraries to retrieve and manipulate data. I’ve been reading about ORM, but I'm not sure if this is the best way to go here. For example, how does this go with stored procedures that use complex sql statements to select data?

    Also, as we have multiple applications that access the same data, we need a way to determine when data changes instead of constantly polling all data using stored procedures. I have read about sql server change notifications, but I'm afraid these would cause a lot of overhead when implemented.


    I'm very interested in hearing your thoughts and advices on what architecture to use and how to implement this according to our needs. There must be a more efficient way to handle this than we do now, especially regarding the polling for data changes.




    An example:

    Customer X has a large factory that distributes chocolate bars. We have created applications for monitoring quality, weighing the amount of chocolate, managing new orders, tracking & tracing, etc. All these applications use a single database that contains tables like "ChocolateMixtures", "Weighings", "Orders", "Logging", “Customers", "ChocolateBars", etc. Applications use different selections of the same data, mostly using stored procedures like "GetChocolateMixtures", "SaveChocolateMixture", "GetMixturesWithOrders", etc. If an employee changes a mixture, the Mixture application as well as the Orders and Chocolate Bars application should be updated.

    • Edited by RensTP Wednesday, November 7, 2012 10:21 AM
    Wednesday, November 7, 2012 10:17 AM

All replies

  • Hi Rens,

    There is a lot of benefit in reusing the Business logic and Data access logic if most of your apps have their own BL and DL.

    Having a cohesive and decoupled Business and Data access services will make your system more maintainable and enable flexibility.

    At this moment, I suggest you look at the architecture from a technology agnostic point of view and not get too hooked up with ORM and ADO.NET instead focus on the application and business services that should be provided by your Business layer.

    I also suggest you do not expose data directly as there is scope for some apps to bypass the business logic and corrupt the database (or themselves). If you are planning to stick with one database then you can keep the Stored procedures as it is but provide a wrapper on top of it so that you decouple the database infrastructure code from your application.

    As a start, I recommend Microsofts Service Layer Pattern (Architecture Patterns for .NET) to structure your architecture and a use case driven requirements gathering to identify areas of reuse and variance.



    Friday, November 9, 2012 11:00 AM
  • Thanks for your response.

    Could you explain what should be in the service layer? It seems to me that it only adds a thin layer between the business and the presentation.

    Also, suppose we go with Microsofts Service Layer Pattern, would you think it's better to create a single service per customer (as nearly all data is somehow related) or multiple services per customer by object / domain?


    Friday, November 9, 2012 12:52 PM
  • As an integrator I see the huge problem in your current state - "as nearly all data is somehow related".

    I would invest resources to architect the data schemas, to make them more independent.

    You have to fight the current spaghetti code. 

    It is not easy but unavoidable step.

    You will not solve your issues with adding new layers in the architecture right now. The app stack might be redeveloped completely. Maybe not. 

    Now you have a great work done with your apps. They could be used as a prototype or as a core.

    If it is a prototype, the development team could recreate all workflow on the new technology basis.

    If it is a core, the development team could create new app without big changes into existed app core.

    Sometimes the middle way is the best way.

    Leonid Ganeline [BizTalk MVP] BizTalkien: Advanced Questions

    Wednesday, November 14, 2012 8:13 PM