Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am working on an asp.net MVC web application which contains several projects.

One is BusinessObjects, which contains business logic / processes.

Another is EmailGeneration which is used to send marketing campaign / customer emails.

The EmailGeneration project references the BusinessObjects project because it need to generate templated emails based on Business Objects.

I need to be able to trigger emails from business objects so that I can, say, automatically send an invoice when an order is completed.

However, I can't add the reference as it would create a circular reference. This suggests that my design is flawed.

How can I change my design to reduce coupling between the components?

share|improve this question

migrated from codereview.stackexchange.com Jan 26 '13 at 17:32

This question came from our site for peer programmer code reviews.

2  
Off topic. Probably belongs on programmers. –  nickles80 Jan 24 '13 at 17:31
    
Can someone move it pls? –  Kryptonite Jan 24 '13 at 17:33
1  
flagged the question for moderator attention for migration –  seand Jan 24 '13 at 21:09

2 Answers 2

up vote 3 down vote accepted

I agree that it sounds like your design is flawed in the fact that your business objects themselves need to send emails. It sounds like this should be done in some sort of domain layer not the objects themselves? Hard to say. Alternatively you could look at creating another project that contains various interfaces for your business objects. Then your dependencies would look like:

Business.Objects => Business.Objects.Interfaces
                 => Business.Email

Business.Email   => Business.Objects.Interfaces

However as pointed out you will probably get more help on SO, or Programmers.

share|improve this answer

I think dreza's answer addresses the coupling issue, but it continues what I see as a common flaw -- multiple projects.

Multiple projects are used a lot more frequently than they are actually required. Unless there is a PHYSICAL need for multiple projects, they simple add complexity without much, if any, benefit. Take your problem as an example, at best, it encourages the low coupling. But you have to create yet another project to implement it, and if you were doing unit testing you would probably come to the same solution from a different direction. And even the encouragement isn't without a potential downside -- the other way to overcome the circular dependency is to split the project off into it's own solution, which just hides the issue.

I would encourage you to go forward with defining an interrface as dreza suggested, but to also look into the possibility of joining any projects you have into a single project. Unless the projects are used by different apps or on different hardware, multiple projects are, IMO, a bad design.

share|improve this answer
    
+1 for multiple projects can add to complexity. We programmers do like to make things more complicated than they need to be at times :) –  dreza Jan 27 '13 at 21:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.