To merge, or just couple?

ajj3085 posted on Thursday, November 02, 2006

Hi all,

I'm writing my contact management / sales / invoicing application. Contact management is pretty much feature complete, and I'm building the sales (quotes & ordering) and invoicing part.

The contact management functionality is contained in a Contacts.Business assembly, and the sales is part of a Quoting.Business assembly. My UI refrences both.

There's also a flat Business assembly, which has an interface definition for Contact, Address and Phone business objects. I had created these so that the Quoting assembly doesn't need to reference the Contacts assembly.

I'm at a point now where the Quoting assembly needs to know more about what's in the Contacts assembly. Is it a good idea to continue what I've been doing, and just creating interfaces, keeping the Quoting assembly from needing a reference to the Contacts assembly? Or maybe it would be better to merge the assemblies so that they can operate as a cohesive unit? Or should I just have Quoting depend on Contacts directly?

Right now the testing assembly for Quoting depends on Contacts already... mainly though just so I can use it to put contact data into the database so that I can test the Quoting objects. I know, its probably not a good idea and lazy, I should probably reference the data assembly and pop the data in that way... but I digress.

So, what's the best way to proceed? I orginally though these assemblies could be used as is if we open up our ordering system directly to our customers via the web... but now I'm not so sure, which leads me to re-evaluate this.

So, of the options, which do you think is the best?

1. Keep quoting and contacts independant of each other, and use interfaces in the common business layer.

2. Let Quoting directly use contacts. This creates coupling... but anymore so than sharing interfaces? I've already had to change the interfaces, contacts and quoting to get something working the way I needed it..

3. Merge the assemblies into one. Are there good reasons to keep them seperate? Right now the users will be using both assemblies, but maybe if I keep them seperate I can give only contacts related functionality to other users as our application grows across the business.

Thoughts?
Andy

Bayu replied on Thursday, November 02, 2006

You do not really explain which forces are causing you to reevaluate this.

- if Contacts are just readonly from the Quoting's perspective, then keep it separate

- if Contacts contain Quoting-related logic, then keep the Contacts assembly clean, add a reference to it from Quoting and implement Quoting-specific subclasses in Quoting

- if Quoting needs more than readonly access (perhaps the full scale of CRUD) to your Contacts, but your Contacts can remain inherently unspecific to their use by Quoting, then keep the separate but keep elaborating your interfaces as you currently do

Reuse is always preferred at the largest possible scale. In the imperative programming days it was on the functional level, with OO it reached the object-level, however: if you can enable reuse on the assembly-level you are king.

Independence (i.e. no reference, but plugin-style loading) is a nice addition. It eases deployment and maintenance. However, it requires you have well-established and fool-proofed interfaces. It seems you in the process of acquiring these. If you can manage to keep the interface generic, as opposed to specific to Quoting, then you are well on your way.

This is of course assuming that you have a potential future need for Contacts. But I guess this a reasonable assumption.

Bayu

ajj3085 replied on Thursday, November 02, 2006

Bayu:
You do not really explain which forces are causing you to reevaluate this.

Ahh, fair enough. Basically its maintainability. I've found so far that if the Quoting assembly needs some information about a contact, I have to first change the interface in the shared business layer, then change the Contacts assembly. Finally, I can finished doing what I need to in my Quoting assembly. So I'm questioning if the most decoupled route is really the most maintainable. The UI knows about contacts, and knows how to look it up and pass it to the Quoting business objects.

Bayu:
- if Contacts are just readonly from the Quoting's perspective, then keep it separate

This is actually something I'm pondering. In my other thread, I talk about how to give the quote busienss objects the information it needs to deteremine if the 'source' data has changed, and raise a flag. The user then has the option to refresh the data. Well, the user also has the option to enter data directly onto the document contact, and push it back to the company or contact.

I can handle this two ways: One way is to have the quoting module 'know' how to update contact info. Not great, because contact data does have rules. The second way would be for the UI to intereprate the Save call, read the new info from the document contact, load up the appropariate Contact edtiable object, and use that to push the changes back into the quoting world. That's the way I think would be best, because I know that I can't accidently break contact business rules.

Bayu:
- if Contacts contain Quoting-related logic, then keep the Contacts assembly clean, add a reference to it from Quoting and implement Quoting-specific subclasses in Quoting

Contacts contain no quoting logic... they may contain data that affects quoting functionality, but its mainly defaults. For example, a contact may be assigned a default price list. Just a simple list, the user can pick any valid value. Of course if that price list is obsoleted by a new price list, the contacts default list should be changed.... this can be handled at the db level though.

Bayu:
- if Quoting needs more than readonly access (perhaps the scale of CRUD) to your Contacts, but your Contacts can remain inherently unspecific to their use by Quoting, then keep the separate but keep elaborating your interfaces as you currently do.

Quotes probaby should directly be updating contact data, it should be kept to read only. The UI might use both to push data into a quote or into a contact based on user commands though. It sounds like keeping them seperate is a good idea and I should continue the interface route as you suggest.

Of course now that I have posted more info, maybe you'll give different advise. Smile [:)]

Thanks
Andy

Bayu replied on Thursday, November 02, 2006

ajj3085:

Of course now that I have posted more info, maybe you'll give different advise.

I was assuming you would prefer to keep them separate since that was your original approach. If the maintainability costs are going to cause too many delays, than merge them now and postpone improved designs until refactory time.

Usually when you have it all working and you start analyzing how you can refactor stuff you can hit the bull's eye in one throw; simply because you know all the details inside-out by now. However, when feasible I still always prefer as much separation as appropriate from the start, so my advice still stands. Wink [;)]

Bayu