ansaurus

Question

Answer 1

+10 A:

Extract interfaces from your classes and put them into a core project referenced from both Billing and Financial projects. You can then use those interfaces to share data between assemblies.

EDIT: This only allows you to pass objects between those 2 assemblies, but you can't create objects from the other since you don't actually have a reference to begin with. If you want to be able to create objects you need a factory, external to those 2 projects, that handles object creation.

EDIT1: As @mnemosyn suggested I would extract the business logic that needs to share the data back and forth between Billing and Financial into another project. This would make things alot easier and would save you from resorting to all sort of tricks that make maintainability a nightmare.

devnull 2010-09-15 16:30:54

And how do I create instances of Financial Objects inside Billing? Example: IAccountPayable a = new ???()

Eduardo 2010-09-15 16:49:30

The data transfer objects that should be used as parameters and return values to pass between Billing and Financial should be defined in the shared assembly, along with the service interfaces. The service implementations would ideally be constructed via a dependency injection framework and provided via constructor arguments to the classes that depend on them.

StriplingWarrior 2010-09-15 17:17:13

I agree this is one possibility, but it requires using a (smart) ServiceLayer and DTOs. However, if the OP is implementing DomainModel, that will not work. But whether DomainModel is the way to go or not depends on lots of criteria, you can't always choose them to be DTOs, in which the whole approach will lead to cumbersome code. Reminds me of the many perils that come with "Enterprise Integration Patterns"...

mnemosyn 2010-09-15 17:34:29

The main drawback of this solution is that interfaces break encapsulation: Interfaces are public by definition and you need to expose much more than you want. Think immutable classes, value types, etc. Moreover, interfaces suggest there are different implementations, e.g. `IOrder` - are there different *types* of order? The same goes for `IOrderItem`, etc. - your code becomes unexpressive and hard to maintain.

mnemosyn 2010-09-15 17:51:38

So it's just a workaround for circular referencing.

Eduardo 2010-09-15 18:12:03

Answer 2

A:

Having too large of a project shouldn't be an issue. You can keep your code structured with namespaces and different folders for the source code. In this case circular references are no longer an issue.

PhilB 2010-09-15 16:35:12

-1. While the statement is *accurate*, it misses the point of the question.

Adam Robinson 2010-09-15 16:41:18

I was responding to the statement within the question "Both are too big so I don't want to put them in a single project.". I think that using folders and namespaces is the correct solution to resolve this problem. Creating additional assemblies should be done when there is a need to deploy the parts of the application independently.

PhilB 2010-09-15 16:47:09

One of the issues of large projects is that many people make changes in the .csproj file, causing too many merges.

Eduardo 2010-09-15 16:51:43

I'm not sure if this is the right solution for your project, but you could consider using wildcards in your csproj file rather than including the individual source code files.

PhilB 2010-09-15 17:01:29

@PhilB: There are other reasons for creating additional projects aside from deployment. Are you saying that the entirety of an application should, if at all possible, be one and only one project? I think that's turning a blind eye to a number of other concerns, not the least of them being proper SOC.

Adam Robinson 2010-09-15 17:34:37

+1 to try to get it back to neutral. The answer (as well as the comments) should at least be considered when circular references pop up. This doesn't deserve a downvote, IMO.

Sam Pearson 2010-09-15 17:51:54

@Adam Robinson: No, I do not advocate attempting to create the entirety of the application in a single assembly. In general I would slice the application into horizontal layers that could be potentially deployed independently, but avoid vertical slices if at all possible. I will retract my original statement as it may be misleading.

PhilB 2010-09-15 18:34:40

@PhilB: What do you mean with horizontal layers?

Eduardo 2010-09-15 18:44:01

@Eduardo: Examples of "horizontal" layers I may use would be UI, Buisness, Data Access. An example of a vertical slice would be splitting the Customer business class into a separate assembly from the Order business class. In general I have found that the vertical slices lead to a lot of interdependent assemblies. This of course can be resolved by adding interface assemblies and factories, but it adds additional complexity.

PhilB 2010-09-15 19:06:47

@PhilB: Your statement was that you would only "slice" the assemblies if there was a *need* to deploy them individually. I would argue that the vast majority of applications will *not* have these layers deployed individually, but I would still contend that the layers belong in their own assemblies.

Adam Robinson 2010-09-15 19:41:29

@Adam Robinson: I agree, "need" was too strong of a word to use here. Maybe "potentially need" would have been better? I think we agree that these concerns should be separated, but I'm curious what the advantages are of separating by assembly rather than separating merely by namespace are (other than deployment of course).

PhilB 2010-09-15 20:21:10

@PhilB: Separation by assembly aids in maintaining SOC, and you can define internal types and members that you can rely on being called only from within the assembly.

Adam Robinson 2010-09-15 20:26:51

Answer 3

+3 A:

The answer mentioning interfaces is correct - but if you need to be able to create both types from both projects, you'll either need to farm a factory out into yet another project (which would also reference the interfaces project but could be referenced by both of your main projects) or change the structure you're using significantly.

Something like this should work:

Finance: References Billing, Interfaces, Factory
Billing: References Finance, Interfaces, Factory
Factory: References Interfaces

Factory would have a BillingFactory.CreateInstance() As Interfaces.IBilling and also the abstract Billing class which implement Interfaces.IBilling.

The only issue I can see is if you need to do something clever when instantiating an object and don't want that logic to end up in a separate project - but as you haven't mentioned any clever logic to instantiate, this should be sufficient

Basiclife 2010-09-15 17:20:05

You mean something like this?MyCompany.ERP.Factories.Billing.CreateInstance(typeof(IAccountPayable))

Eduardo 2010-09-15 17:30:20

Yes - It's then the responsibility of the factory to create your concrete instance and return it. This can be called from any other location. Where the abstract AccountPayable class which implement IAccountPayable lives will depend on how complex it is - if it's simply a POCO, it can live somewhere simple (ie instead of an interfaces project, have a common or entities project). If it's complex and has its own logic, you're going to need to restructure slightly - as you wouldn't want all your business logic scattered around in common projects...

Basiclife 2010-09-15 17:43:36

We use: a Project.BusinessLogic assembly which contains "Managers". Managers are classes which deal with entities in a Project.Entities assembly - The UI talks to managers which hold the logic for manipulating the entities. Managers can either manipulate or return entities. Entities in our case are very simple POCOs. Managers also have a CreateInstance() method which returns a new entity.

Basiclife 2010-09-15 17:46:41

The solution in the above comment may not be appropriate in your case - as I said, it depends where your logic lives.

Basiclife 2010-09-15 17:47:36

But if ManagerA calls ManagerB in some point and ManagerB calls ManagerA you have the same problem.

Eduardo 2010-09-15 19:09:00

True - but you need to draw the line somewhere. You can't have 2 objects that refer to each other and can both manipulate each other - it's just not possible to compile. You either need to abstract using interfaces or avoid the issue with your design. The way we get around this is to have "Services" which reference multiple managers - ie managers are responsible for handling a particular entity, services manipulate multiple entities. Of course, again services can't reference each other - but this hasn't proved to be an issue for us...

Basiclife 2010-09-16 09:57:10

ansaurus

tags:

views:

answers:

How to deal with circular references?

related questions