Design – Layered architectures and modular software

I agree that what you are validating will be different in each layer of the application. I typically only validate what is required to execute the code in the current method. I try to treat the underlying components as black boxes and don't validate based on how those components are implemented.

So, as an example, in your CashDropApi class, I would only verify that 'contract' is not null. This prevents NullReferenceExceptions and is all that is needed to ensure this method executes properly.

I don't know that I'd validate anything in the service or command classes and the handler would only verify that 'command' is not null for the same reasons as in the CashDropApi class. I've seen (and done) validation both ways wrt to the factory and entity classes. One or the other is where you'd want to validate the value of 'amount' and that the other parameters are not null (your business rules).

The repository should only validate that the data contained in the object is consistent with the schema defined in your database and the daa operation will succeed. For example, if you have a column that can't be null or has a max length, etc.

As for the security check, I think it is really a question of intent. Since the rule is intended to prevent unauthorized access, I would want to make this check as early in the process as possible to reduce the number of unnecessary steps I've taken if the user is not authorized. I'd probably put it in the CashDropApi.

In order:

1. Is there something which allows you to assert that the application is slow? Is there a non-functional requirement related to performance that the application doesn't fulfill any longer? Does it feel slow (in which case your first concern should be to write down a non-functional requirement which will explicitly tell what are you expecting)?

   If the application is fast enough, you're doing premature optimization. Please, don't do that.

2. What are the results when you profile the application? Have you profiled it and identified that the fact that you're doing three queries instead of one is the bottleneck which affects the performance in a very noticeable way?

   If not, do this first. Run profiling, identify the bottlenecks. Very probably, you'll find that the number of queries (3 vs. 1) is your least concern in terms of performance.

   Note that connection pooling (if you're using Microsoft SQL Server) reduces considerably the cost of closing and reopening a connection several times. Make sure you close your connections properly, i.e. you dispose the resources. You should have using () { } around all SqlConnections, SqlTransactions, SqlCommands, etc. The static checking tool called Code Analysis helps you finding the stuff not properly disposed.

   Remember to profile your views as well. Execution plans are particularly useful in this case. Watch for the indexes (not necessarily the lack of them, but also which ones are there and why). Look at the data you load and the data you actually need (sometimes, developers load too much data from a database, and only then filter it at application level; this is unfortunate, since databases do the filtering job very well themselves).

   If you're using an ORM, watch the queries it builds (you may use SQL Server Profiler for that; most ORMs also allow to log the queries they send to the database). Sometimes, ORMs need help for figuring out the best way to build an optimized query.

3. Do you use caching?

   If not, you may want to focus on that first, before dealing with multiple queries vs. one query. Since you're talking about views, I imagine that you're not modifying data, but only reading it (although, you can modify data through views in Microsoft SQL Server). This means that this data can very probably be cached on the server, which means that instead of 3 or 1 queries, you'll have 0.

Only then, i.e. only if you know that the application doesn't respond to a non-functional requirement of performance, that it is slow because it does three queries instead of one and that caching won't help should you be concerned by optimization consisting of replacing three queries by one.

Remember that you're not necessarily forced to do it through a stored procedure. In your particular case, since all you do is to access three views, creating a fourth view can be the solution.

In all cases, I'm surprised that you have found that (or that you believe that) performance is affected on I/O level by three queries instead of one:

• What could have been the issue is to close and reopen connections two times. As I previously said, connection pooling solves that.

• In general, the time spent sending a query to an SQL server is nearly zero compared to the time spent reading the data back, unless you're querying a scalar value.

• In general, the time spent sending a query to an SQL server is not as important as the time spent by the SQL server loading the data (given that most SQL servers do a great job of caching data in memory, which makes most queries outstandingly fast).