Theory Question

What's the easiest to maintain? That should be your primary concern. I can almost guarantee you that this function(s) are going to change in the future. If you have ONE method, you have a very good chance of breaking something when you update it. That being said, you definitely want to compartmentalize your code so that it's easier for new developers that look at your code to debug, understand, maintain, and extend without breaking something... and be able to do it quickly. Don't worry about "more programming" or "less programming". When you try to save on programming, someone pays the "interest" later. Just do it right. It sounds like this is pretty big, so I'm leaning towards the latter (a few GetAllMyData type methods). Optimization will be necessary no matter what, so less maintenance is almost always the deciding factor. Optimizing monolithic code can be a real nightmare, especially after it's gone through dozens of revisions over the life cycle of the program.

Generally speaking I'd go with option A, though there'll be exceptions (always is in I.T., right?). The problem I see with GetAllMyData() is that it doesn't really reduce the programming effort; it just moves it from the business object to the client, where it doesn't belong. Example. You've just assigned Developer1 to write a client app that displays the data either by customer or by month. So he makes a screen that lets user enter customer id or month, and then he calls GetAllMyData(). The client app now has to have the intelligence to cull through the results and display for the given month or customer. This obviously is done a lot more efficiently on the server than on the client, so it'd be better if the client could call a couple different methods, depending on what the user wants, e.g. GetDataForCustomer(int ACustomerID) or GetDataForMonth(int AMonth). It can get worse. Let's say there's a business rule that the month ends on the last Sunday of the month. So when Developer1 wrote the client app above, he had to program in that logic, say into a C# windows app. Now users in the field want to get at that data via the web. So you assign Developer2 and he builds a web client, say using Java. In the best case he calls GetAllMyData() and essentially re-writes the same algorithms in Java that had been written in C#. Worst case is he's not aware of the eom rule and writes the algorithm for a calendar month. Now the web users are seeing different data than the window app users and boy are we in trouble. These problems are minimized by having a GetDataForMonth(int AMonth) method in the business class that "knows" what a month really is. All clients calling GetDataForMonth get the same results. All that being said, I think there are circumstances when it might be advantageous to bring back more data than the client might need, but this message is long enough. As this thread progresses, I may toss out some other ideas. My main immediate concern is your statement about more or less programming being required between A and B. I think you're going to have to program it somewhere, it just depends where.