Determining the best way to break up code into different folders and namespaces

Question

i have the following directories:

-UI
-BusinessLogic
-DataAccess
-BusinessObjects

if i have a class that is a client stub to a server side service that changes state on a server system, where would that go . .

Answer 1

I would consider this a form of data access, although it's not clear to me that you need to put it in the same project as the rest of your data access classes. Remember that the layers are mainly conceptual -- to help you keep your design clean. Separating them into different projects helps organizationally, but is not mandatory. If it's an actual stub class, then the data access project is probably the natural home for it, but if it's only used in the UI layer, then keeping it there would probably be ok.

Answer 2

In a web service repository.

Answer 3

I don't think it belongs in any of those. You either need a new directory or a new project entirely. But out of those given, I would have to say BusinessObjects because it's certainly not accessing data according to your description, and rather is simply acting like a local object (stub).

Answer 4

this code belongs in the recycle bin ;-)

seriously, if you wrote it and don't know where it goes, then either the code is questionable or your partitioning is questionable; how are we supposed to have more information about your system than you have?

now if you just want some uninformed opinions, those we've got by the petabyte:

1. it goes in the UI because you said it's a client stub
2. it goes in the business logic because it implements the effect of a business rule
3. it goes in the data access layer because it is accessing a state-changing service
4. it goes in the business object layer because it results in a state change on the server

it would be more helpful if you told us what the stub actually does; without specifics it is hard to know where it belongs, and/or it is easy to argue in a vacuum about where it "should" belong