Suggestions needed on design

Suggestions needed on design

Old forum URL: forums.lhotka.net/forums/t/2788.aspx

ajj3085 posted on Thursday, April 26, 2007

Hi,

I have a program which right now is just a contact management system.  I'm adding quoting, ordering and invoicing functionality to the progrm as well, so that my users can use one program to do everything.

As part of the use case for editing documents, users must fill out sold to, bill to, and ship to information.  They can enter data free form, or they can select a contact or department.    So far, so good.

I designed assemblies so that the contacts portion is seperate from the quoting portion.  In the few instances the layers need to communicate, I have defined interfaces to allow them the communicate indirectly. 

Here's the part I'm having trouble with.  As part of the use case, the users would like to be able to save changes made in the document screen back to the contact.  The document doesn't require any particular fields, such as first name and last name, but the contact module does require those fields.  Also, there should be a button to pull the current contact information from the system (as the document keeps its own copy of this data, because its sometimes changed for only this particular order, and later to maintain history). 

My problem is, how do I give this functionality to the users?  The quoting assembly doesn't know the rules for editing a contact, but they still need to be enforced if the user elects to save changes back to the main contact record. 

I could merge the assemblies, but I'd like that as a last resort.  The reason is that other applications may share some of the same use cases, and ideally they would not need to reference an assembly only to use 10% of its functionality.

Thanks
Andy

Bayu replied on Friday, April 27, 2007

Hi,

If multiple apps (or separate modules of 1 app) need the same business logic then I guess it is perfectly valid to make each them have (direct) access to this logic. That's the whole point of reuse, right?

So I think putting interfaces in-between is just making simple things overly hard. in this particular case Although I do agree that interfaces are good for decoupling modules, in this case both modules simply require direct access to the logic imo.

If you say only 10% of your contacts module is actually candidate for reuse, then why not make an additional module to put all the shared BOs in? This 'shared' (or 'common') library would then contain this 10% that you wish to be reused, the other 90% can stay in a 'dedicated' contacts module and your quoting/financing/etc. module can reuse the 10%.

Bayu

RockfordLhotka replied on Friday, April 27, 2007

Another way to look at this, if you really want to keep strict separation, is to use service-oriented concepts to interact between your assemblies.

In other words, your Contact assembly could expose a "service-oriented" interface (not web services or anything - just message-based) where a caller can call the service to request a change to the Contact data. Then the change would occur inside the contact assembly, where the rules could be enforced.

To do this, your Contact assembly would expose a DTO (message or data contract) and an interface with an UpdateContact() method that accepts that DTO. The caller would put the data into the DTO and call the method (service), and the work would occur in the Contact assembly.

If you want to be even cleaner, you could create a ContactService assembly that would be, technically, a UI layer. This is where you'd put the DTO, interface and service implementation.

ajj3085 replied on Friday, May 11, 2007

RockfordLhotka:
If you want to be even cleaner, you could create a ContactService assembly that would be, technically, a UI layer. This is where you'd put the DTO, interface and service implementation.


This is the method I'm going to pursue.  It sounds like a nice clean way to acomplish the seperation I'm shooting for.  I have one last question regarding this topic though:  how to I communicate the broken rules back to the UI?  I'll need a way to tell the user why the update will not work.

Thanks
Andy

RockfordLhotka replied on Friday, May 11, 2007

Well, you have hit on the major drawback to this SOA-style approach… The thin client is dumber than a rock – much like a typical web browser.

 

So you have the same options the web world has, which means that you can

1.       Duplicate some/all of the logic in the client application (remember, it is a separate app from the service app – so don’t share code or you’ll get into a versioning nightmare)

2.       Use a “block mode” approach where the user enters data, sends it all to the server and gets a laundry list of issues back

3.       Send data to the service field-by-field for validation (NOT RECOMMENDED, AND NOT SERVICE-ORIENTED)

 

Even if you do #1, btw, you still have to do #2, because the service itself must obviously be self-sufficient.

 

This means that your contract definition must include both client->server requests, server->client response, where “response” includes details about success or failure.

 

Rocky

ajj3085 replied on Wednesday, May 16, 2007

RockfordLhotka:
2.       Use a “block mode” approach where the user enters data, sends it all to the server and gets a laundry list of issues back


This is the approach I will take.  The 'services' layer will be mearly a thin wrapper around the contacts assembly.  So the method will function much like a TryParse, returning true or false to indicate success and the second parameter is an 'out' of BrokenRulesCollection.

Thanks for the feedback!
Andy

david.wendelken replied on Monday, April 30, 2007

ajj3085:
Hi,

Here's the part I'm having trouble with.  As part of the use case, the users would like to be able to save changes made in the document screen back to the contact.  The document doesn't require any particular fields, such as first name and last name, but the contact module does require those fields. 

Um...  Why not have them fill in the correct fields (first name, last name, etc.) as part of the document?  Then it would be simple. 

ajj3085 replied on Monday, April 30, 2007

The answer is just as simple; that's not the requirement for the contact information on a document.

david.wendelken replied on Monday, April 30, 2007

ajj3085:

The answer is just as simple; that's not the requirement for the contact information on a document.

Should it be? :)

Even if it isn't, with a bit of ingenuity I bet you could set up the document UI so that users could free-form things or fill in the data into mapped fields, as they chose.  You could even use the same fields.

Just a thought.  Use or ignore as you please!

Copyright (c) Marimer LLC