Reference question/problem (design discussion)

[CompiledMonkey]

Ok, I�m going to do my best trying to explain this, so go along with me.

 

I�m working on a class project called BarHopper. The goal is to build a Pocket PC, GPS enabled, GIS where users can mark their favorite bars and plan out their night with a route of bars to �hop� to. That said, I wanted to build a framework that could be used to build variations of BarHopper for any application, such as an application for marking wireless Internet access in your town with X and Y coordinates, etc. So, I designed the Locator framework with namespaces and classes that you�d need to build a BarHopper derivative. Most of which are abstract classes that implement interfaces. I had planned to build the BarHopper.dll with extensions of the Locator.dll classes and interfaces, which I�ve done, but I have an issue. Let�s take the User object as an example. In the BarHopper.dll, User is an object that extends Locator.People.Person which is an abstract class in the Locator.dll. I setup the User object to Save and Delete to my database and everything seemed fine. When I tried to consume the User object in a test project, not only did I have to reference the BarHopper.dll, but I also had to reference the Locator.dll. Can anyone tell me why? The message VS.NET gave me was:

 

�The type 'Locator.People.Person' is defined in an assembly that is not referenced. You must add a reference to assembly 'Locator.People��

 

In the past, I�ve been able to do something similar and not worry about referencing anything in the Locator.dll from my client application because everything I needed from Locator.dll was extended into the BarHopper.dll. I thought all I would need is a reference to that BarHopper.dll in a client. If I have to reference both, there isn�t much reason to separate the two.

 

Hope I explained the situation well enough. I�d love to get some conversation going over this.

[bri189a]

If People is defined in Locator (which it appears to be) and BarHopper uses it then yes you have to reference it.

 

Perhaps you should look at making your design model the domain. In otherwords - Locator I gather is the 'GPS' system. Does a Locator use a person or does a person use a locator? I would have the 'Locator' all on it's own and have no knowlege of what is using it. Other things can use a locator besides a person - a car, another computer system, etc. - I would have external interfaces for the Locator that could be used by anything. People would be a seperate object that has the ability to use 'Locator' and probably would be the general responsible object (look up GRASP) for entering objects into the Locator, whether it be a Bar, a grocery store, or whatever else that can have a physical location (which the Locator would need). But keep in mind, something other than a 'person' could enter objects into a Locator - so again I wouldn't couple any relationship between Person and Locator.

[CompiledMonkey]

Well, I do have a seperate project, and therefore seperate assembly for each Locator namespace. So Person has no ties to the GPSData, or GPSDevice classes, and so forth. They are in the same high level namespace (Locator), but nested into different namespaces as you move down the tree. I used the .NET framework itself as a reference to model the Locator.dll.