Sorry, I copied this from the General Chat. Seems to be a better fit here..

Let's say I have two business service components which contain my BL controller classes (they are also located in diff. assemblies). One is Accounting and one is Sales. Now, accounting needs to use the services from the sales components, so the accounting dll has a ref to the sales component. Also, the sales has to use the services of the accounting dll, so he has a ref to the accounting dll. Since this is a circular dependecy, is this considered bad design?

This is likely better off in the General Chat area, since it's not about LLBL Gen.

It's hard to answer your question completely based on the information you've supplied (without knowing your overall architecture, etc.).

But, in very broad terms, that doesn't sound like the best design from your brief description.

Are they utility methods? Can you have a Utility assembly that all your "business assembly controller classes" have access to?

psandler wrote:

But, in very broad terms, that doesn't sound like the best design from your brief description.

Are they utility methods? Can you have a Utility assembly that all your "business assembly controller classes" have access to?

No, they are not utility classes. Basically, I have a Facade Layer, which contains a manager class (Controller) for each table in the database. There are two different databases involved here; Accounting and Workers Comp (I know..I said sales). Accounting need to pull data from the workers database, and workers needs to pull some data from the accounting database. In order to re-use our cross domain functionality, each divison has their own business / data components. As you know, it would be silly to not reuse there services already tested and developed.

A suggestion might be to identify the methods and pull them out into a third assembly, or even combine the two assemblies into one. At the philosophical level, there isn't anything wrong with reusing the functionality; it's the physical packaging that makes it problematic.

Jeff...

jeffreygg wrote:

it's the physical packaging that makes it problematic. Jeff...

Thanks for the feedback Jeff. What do you mean when you say physical packaging? Without testing, I would bet if I ran an application with this scenario is would run correctly, however, the visual studio ide would not be able to support this. Just a guess though..

Correct. VS will not allow circular dependencies, but I believe you can compile your scenario successfully outside of it. By physical packaging I meant where the code is physically stored: in separate assemblies.

Jeff...

KristianP wrote:

psandler wrote:

But, in very broad terms, that doesn't sound like the best design from your brief description.

Are they utility methods? Can you have a Utility assembly that all your "business assembly controller classes" have access to?

No, they are not utility classes. Basically, I have a Facade Layer, which contains a manager class (Controller) for each table in the database. There are two different databases involved here; Accounting and Workers Comp (I know..I said sales). Accounting need to pull data from the workers database, and workers needs to pull some data from the accounting database. In order to re-use our cross domain functionality, each divison has their own business / data components. As you know, it would be silly to not reuse there services already tested and developed.

Can you break each domain into two assemblies. So, the works comp entities that sales needs are in a seperate dll?

For example...

WorkComp.dll WorkCompShared.dll

Accounting.dll AccountingShared.dll

Accounting.dll will reference WorkCompShared.dll WorkComp.dll will reference AccountingShared.dll

If possible, this way there are not circular references.

Or, have a single assembly that talks to two catalogs but has the common entities in them...

Accounting.dll WorkComp.dll AcctWorkCompCommon.dll

BOb

Accounting.dll WorkComp.dll AcctWorkCompCommon.dll

Personally, I think this is a cleaner design. However might want to consider

Accounting.dll WorkComp.dll IAcctWorkCompCommon.dll AcctWorkCompCommonIMP.dll

Note: IAcctWorkCompCommon is an interace AcctWorkCompCommonIMP is an implementation of the AcctWorkCompCommon.

You can then swap in/out AcctWorkCompCommon with ease.