My DBA is afraid of O/RM. How can DBAs benefit from O/RM?
Some DBAs resist the notion of O/RM. The typical starting point here is that the DBA will only allow you to execute stored procedures on their database, reasons of performance and security.
Performance first: some 95% of all queries in an application are standard, ordinary cases (simple queries, basic CRUDs), which can be translated with ease by an O/RM. These standard cases do not allow for great creativity or genius; they just need to be done, so whether they are performed by a tool or the DBA is of no concern. But then there are those 0 to 5% of queries that end up requiring hand-tuning. Genome will allow you to handwrite those queries, leaving open all possibilities to tune for performance. Your DBA can thus focus on the handful of queries that really require expertise and attention, while Genome takes care of the dull, ordinary ones. Please also consider that it is not possible to predict which 5% of the queries will be affected - you have to implement, test for performance and then isolate the bottlenecks in any case.
Contrary to popular belief, the DBA does not lose control over the database schema. We hate it when O/RM tools demand certain database schemas - they have ruined the reputation of O/RM in the DBA world. It makes us want to scream. Genome is NOT like that!
We consider a DBA's input on the database schema both valuable and necessary. Developers generally neither care about nor want to deal with the schema, and hence need the DBA. Also, the O/RM cannot determine an optimal database structure.
In fact, this is a common misconception; generating a database schema is not the same thing as deciding what that schema should look like. First of all, generating a schema is an optional step. Second, it is the DBA's decisions that determine what sort of schema is generated. That information is written into the mapping file, but not by Genome.
Genome leaves the DBA in control of the schema, but also allows for a much larger time window during which changes can be made. Different schema approaches can be profiled effortlessly with the near-ready application and decisions can thus be based on experience and actual profiling results. With a handwritten DAL on the other hand, it is unlikely that you can easily turn around your database schema when you have nearly finished the project. The bottom line is that Genome grants DBAs more, not less, control and in no way dictates the schema.
Aside from that, anything handwritten is generally less agile and involves higher levels of effort during maintenance.
As regards security, DBAs may be interested to know that SQL generated by Genome is 100% safe against SQL injection. In fact, generating standard queries with a tool is thus the safest way of all. DBAs can also review queries generated by Genome to verify this, which would still require less effort than handwriting and maintaining them in the first place.
While we're on the topic, a little side note about dynamic queries: cropping up in virtually every project, such queries depend on parameters that are determined during runtime (user input, time, etc). A typical example of this is a search form where the user can enter various criteria (or not) and possibly decide which associated data should be retrieved. Based on this information, a query is generated. Essentially, building this query dynamically means using business logic. If your SQL is manually coded, this results in business logic in your stored procedure and string building for your query - both undesirable. Business logic in your database is both difficult to maintain and hard to use with logic in the middle tier. As for string building, it is difficult to test and represents a security risk.
With Genome on the other hand, logic safely remains in the middle tier, without generating additional database roundtrips. The result is a generated SQL statement that fulfills all dynamic requirements. The query is shaped with LINQ and a strongly typed API: no runtime errors, no security risks.