locked
Avoiding Circular References with Application Architecture RRS feed

  • Question

  • I would like to hear comments and suggestions on the proper way to avoid circular references between projects.

    Consider an app with the following assemblies:

    - UI
    - BusinessLogic
    - DAL
    - Common

    So typically, the dependencies would look like this:
    UI >> BusinessLogic >> DAL
    and all 3 above depend on Common

    So far, so good, but... lets say that I have a common collection of data that is required to be used in all 3 of the main assemblies, such as a list of supported cultures.

    So I create a static helper class in the Common assembly and this gives me access to the shared singleton collection from all 3 main assemblies.

    However, to populate that singleton collection when the app starts, I need to hit the database once. To do this right, I would load the collection from the database using my BusinessLogic layer.

    But I cannot do this because doing so would cause a circular reference between Common and BusinessLogic.

    What is the best architecture to avoid/work around this problem?

    Thanks.
    Wednesday, January 21, 2009 2:15 PM

All replies

  • You can build your application around a Model/Entity/Domain objects.  What you call the common collection of data is same as Entity objects.  One simple way is DTO pattern.  Personally I dont use DTO, I use Model driven architecture and derive my UI, BL and DAL around the model.  Please take a look at www.gajakannan.com/netarch.aspx and supporting word document where I have explained an architecture for a fictionary pharmacy application around this model.

     

    { Gaja; }

    http://www.gajakannan.com

    Wednesday, January 21, 2009 4:09 PM
  • Hi Gaja, thanks for your reply.

    The example I provided has been simplified.  Our actual architecture is closer to the one you posted than my sample, but my issue still remains, and perhaps it is a problem of our organization of classes.

    We currently have the equivalent of a DTO assembly, in fact we have 2, a DTO Entity whose scope is UI thru WCF to the BusinessLayer and another internal set of business entity objects whose scope is from BusinessLayer to DAL.  A DTO object is mapped to a business entity object.  These objects are typically data carriers that do not contain behaviour.

    My confusion lies in properly organizing classes that do have behaviour and could be called from any of the other assemblies.  This by itself is not an issue, but if the helper class depends on data from the database, then it becomes an issue, with a circular reference.

    One way I can think of to fix the issue would be to promote my helper class in the Common assembly to a service, with a self contained DAL.

    So to use an example from your architecture diagram.  If the Messaging, Authentication or Authorization components required data from the database, how would they go about loading it?  Would they use their own internal methods? Because if they called to the BusinessProcessLayer for the data, it would create a circular reference.

    thx

    Wednesday, January 21, 2009 7:13 PM