Avoiding Circular References with Application Architecture
-
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.
Leftyfarrell wrote:
What is the best architecture to avoid/work around this problem?
Don't know how you will take this, but my opinion will be as follows, The common will contain only the DTO structure of the data you are concerned about. for example you common can have a class roughly something like
namespace Common {
public class SupportedCultures : Collection {}
}// now you DAL should have an interface like
ICultureDal { Common.SupportedCultures GetSupportedCultures();}
//Now, in the buiness layer,
IBusinessServices
{
Common.SupportedCultures GetSupportedCultures();// it will use the ICultureDal to get the data
}now you client application will use the IBusinessServices to get the list of culture and may be cache it as needed to avoid further business calls. (you can also cache it at your service layer)
Moim Hossain R&D Project Manager BlueCielo ECM Solutions BV
-
Leftyfarrell wrote:
What is the best architecture to avoid/work around this problem?
Don't know how you will take this, but my opinion will be as follows, The common will contain only the DTO structure of the data you are concerned about. for example you common can have a class roughly something like
namespace Common {
public class SupportedCultures : Collection {}
}// now you DAL should have an interface like
ICultureDal { Common.SupportedCultures GetSupportedCultures();}
//Now, in the buiness layer,
IBusinessServices
{
Common.SupportedCultures GetSupportedCultures();// it will use the ICultureDal to get the data
}now you client application will use the IBusinessServices to get the list of culture and may be cache it as needed to avoid further business calls. (you can also cache it at your service layer)
Moim Hossain R&D Project Manager BlueCielo ECM Solutions BV
That works for core concerns...business concerns. But the original question was in regards to cross-cutting concerns. Cross-cutting concerns are things like logging, validation, instrumentation, security, context, etc. These don't really fall into the categories of business services or DTOs. Cross-cutting concerns are one of the major pain points in software development today, and the driving force behing things like AOP, Aspect-Oriented Programming. AOP aims to privide a mechanism to separate cross-cutting concerns from your core concerns, and apply them in an alternative, configurational manner (possibly adjustable at runtime).
-
That works for core concerns...business concerns. But the original question was in regards to cross-cutting concerns. Cross-cutting concerns are things like logging, validation, instrumentation, security, context, etc. These don't really fall into the categories of business services or DTOs. Cross-cutting concerns are one of the major pain points in software development today, and the driving force behing things like AOP, Aspect-Oriented Programming. AOP aims to privide a mechanism to separate cross-cutting concerns from your core concerns, and apply them in an alternative, configurational manner (possibly adjustable at runtime).
Are you certain the OP's topic of loading a collection of supported cultures fits that category? Doesn't seem like it should. I am always suspicious that a static helper class is a indication that some refactoring might be in order.
Leftyfarrell wrote:
So I create a static helper class
led mike
-
Are you certain the OP's topic of loading a collection of supported cultures fits that category? Doesn't seem like it should. I am always suspicious that a static helper class is a indication that some refactoring might be in order.
Leftyfarrell wrote:
So I create a static helper class
led mike
Well, my other response described my recommended solution. I agree, statics are something that should generally be avoided. An area where statics can be helpful is in creating simple facades that wrap up complex frameworks into simpler ones. There is always a cost involved in every decision like that though.
Leftyfarrell wrote:
The heart of my question really has to do with cross cutting concerns like Logging, Exception Handling, Validation, Instrumentation etc.
The above statement is what I am basing all of this on. Cross-cutting concerns are those that permate every aspect of your application, all layers, all levels. They are difficult to neatly package up into well-isolated "areas" like a presentation or business layer, a service, whatever. Lefty's validation loads localized messages from a database, caches them in a static class, and spits them out whenever a validation error occurrs. Even though localized text is involved, it doesn't change the fact that were talking about a cross-cutting concern. Its just a cross-cutting concern that happens to access a database. The choice to use a static class to hold the cached localization data is probably fine...perhapse even ideal, if the messages rarely or never change. Data that seldom changes is technically static anyway.
-
Well, my other response described my recommended solution. I agree, statics are something that should generally be avoided. An area where statics can be helpful is in creating simple facades that wrap up complex frameworks into simpler ones. There is always a cost involved in every decision like that though.
Leftyfarrell wrote:
The heart of my question really has to do with cross cutting concerns like Logging, Exception Handling, Validation, Instrumentation etc.
The above statement is what I am basing all of this on. Cross-cutting concerns are those that permate every aspect of your application, all layers, all levels. They are difficult to neatly package up into well-isolated "areas" like a presentation or business layer, a service, whatever. Lefty's validation loads localized messages from a database, caches them in a static class, and spits them out whenever a validation error occurrs. Even though localized text is involved, it doesn't change the fact that were talking about a cross-cutting concern. Its just a cross-cutting concern that happens to access a database. The choice to use a static class to hold the cached localization data is probably fine...perhapse even ideal, if the messages rarely or never change. Data that seldom changes is technically static anyway.
Jon Rista wrote:
They are difficult to neatly package up into well-isolated "areas"
I guess I don't understand, I have never run into any unusual problems isolating the concerns you specified. Here I use the word isolate regarding both a design and packaging perspective, which avoids any circular issues.
led mike
-
Jon Rista wrote:
They are difficult to neatly package up into well-isolated "areas"
I guess I don't understand, I have never run into any unusual problems isolating the concerns you specified. Here I use the word isolate regarding both a design and packaging perspective, which avoids any circular issues.
led mike
I mean it from the perspective of use I guess: When you write a Controller, you put that controller in a project that is part of the "presentation layer" of your application. All controllers will be in the presentation layer...you won't have any in the business or data access layers. You have neatly grouped all your controllers into a single area, and they will only be USED by other things in your presentation layer. When you write a Business object, you put that service in a project that is part of the "business layer" of your application. All services will be in your business layer...you won't have any in the data access layer or in the presentation layer. You will transform business objects or graphs into DTO's for transfer accross the wire to your presentation layer and back. You have neatly grouped all your business objects into a single area, and they will only be USED by other things in your business layer. Cross-cutting concerns can not be isolated like that: When you write a logging framework, you put the logger class and its support types in a "shared" area. Your logging functionality is neatly encapsulated in the shared area of your application. Your logger will be used in MANY places, accross your layers, including presentation, business, and data access layers. Your logger's use is not neatly grouped, it is scattered throughout your application, and there is no way to keep usage of logging, a cross-cutting concern, isolated to a single area of your application.
-
I mean it from the perspective of use I guess: When you write a Controller, you put that controller in a project that is part of the "presentation layer" of your application. All controllers will be in the presentation layer...you won't have any in the business or data access layers. You have neatly grouped all your controllers into a single area, and they will only be USED by other things in your presentation layer. When you write a Business object, you put that service in a project that is part of the "business layer" of your application. All services will be in your business layer...you won't have any in the data access layer or in the presentation layer. You will transform business objects or graphs into DTO's for transfer accross the wire to your presentation layer and back. You have neatly grouped all your business objects into a single area, and they will only be USED by other things in your business layer. Cross-cutting concerns can not be isolated like that: When you write a logging framework, you put the logger class and its support types in a "shared" area. Your logging functionality is neatly encapsulated in the shared area of your application. Your logger will be used in MANY places, accross your layers, including presentation, business, and data access layers. Your logger's use is not neatly grouped, it is scattered throughout your application, and there is no way to keep usage of logging, a cross-cutting concern, isolated to a single area of your application.
Jon Rista wrote:
Cross-cutting concerns can not be isolated like that:
Ah, yes because then it would not be cross-cutting. I thought we were talking about the library design creating the circular problem not the user code creating the circular problem. My bad.
led mike
-
Jon Rista wrote:
Cross-cutting concerns can not be isolated like that:
Ah, yes because then it would not be cross-cutting. I thought we were talking about the library design creating the circular problem not the user code creating the circular problem. My bad.
led mike
No problem. I think I kind of confused the issue anyway by using the term "packaging". :P I've been delving deep into AOP with the PostSharp framework lately, so my perspective on things is a bit skewed from the norm right now. From the AOP perspective, aspects kind of referr to usages. If full AOP capabilities existed in .NET, you could "package up" aspects and apply them to multiple points in your code using external means. This allows a more appropriate separation of concerns, allowing you to neatly isolate cross-cutting concerns from core concerns. PostSharp doesn't yet allow such flexibility in applying aspects, but its getting close.
-
No problem. I think I kind of confused the issue anyway by using the term "packaging". :P I've been delving deep into AOP with the PostSharp framework lately, so my perspective on things is a bit skewed from the norm right now. From the AOP perspective, aspects kind of referr to usages. If full AOP capabilities existed in .NET, you could "package up" aspects and apply them to multiple points in your code using external means. This allows a more appropriate separation of concerns, allowing you to neatly isolate cross-cutting concerns from core concerns. PostSharp doesn't yet allow such flexibility in applying aspects, but its getting close.
-
That sounds cool. It was nice to talk with someone that can speak design for a change. Thanks. Have a great weekend :beer:
led mike
-
led mike wrote:
It was nice to talk with someone that can speak design for a change. Thanks.
Agreed! :beer:
Great discussion guys. Thanks for the comments and sorry I was away for a while... this tab got lost within 40 others in my Firefox window... For now, what we wound up doing is something like this: Global.Common assembly contains base classes for Validation. Logic to load validation error message strings is different depending on what "area" of the application you are calling validation from, ie. UI vs. BLL Each of our "areas" also has an assembly for common code (shared among the assemblies in that area) so we have: UI.Common and BLL.Common For the validation example... we created a validation class in UI.Common that inherits from Global.Common, but provides its own implementation that loads the message strings from our BLL by calling through WCF. We will create another validation class in the BLL.Common that inherits from Global.Common, but this implementation will call the BLL methods directly to load the message strings, without going through WCF. This way, the cross-cutting concerns are kept within the 3 Common assemblies and uses a provider model idea for the loading of message resources.