> We used stored procedures extensively. We chose to limit the logic of > each > stored procedure to one database.
I'm not sure how you'd do anything else. > The data layer objects (which were in > separate components/assemblies pulled data out of the required data > stores, > performed some conversions, and presented a sanitized object model to the > business logic. (If your responce at this point is "How ugly!", your > response matches mine; however, the system works and was much less costly > than rewriting everything.) Well, other than the fact that I would tend to prefer a single set of components rather than data and business logic, I don't find this particularly ugly. And depending on the degree of coupling between the two layers, you might be doing as well as you could anyway. The place where people get into trouble is when they make the data layer "reusable". As long as you couple it tightly to the business layer, you can still get away with making just one call to the data objects layer in the mid-tier. If you only have one call, optimization is still possible. Full optimization is not possible when you have more than one call to whatever is talking to the database. > If network optimization is the primary requirement, this is almost > certainly > not the way to do this. However, if the requirements are as I have > described them above, I do not know how else one would approach this. Here's the thing: you didn't include "scalability" or "performance" as a requirement. If it's not a requirement, then you don't care about network roundtrips. If it is a requirement, then *for sufficiently high scaling requirements* database locks usually become your primary bottleneck. In that case, network roundtrips are the biggest killer. But again, if your system meets your scaling needs as-is, then good. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
