Register       Login  
   Small text Medium text Large text
  Useful links  
   
         
     
  Announcements  
 
Genome 4.2 SP8 supports VS2013 and .NET 4.5 - Thursday, October 24, 2013
Genome v4.2.9 provides integration to Microsoft Visual Studio 2013 with the same functionality as for VS2010 and VS2012. Also with this update the DataDomain schema projects can be compiled to .NET 4.5 and .NET 4.5.1 too. The service pack contains a few minor fixes in the runtime too.  
Genome 4.2 SP7 released - Wednesday, May 01, 2013
With a few fixes and a small feature!  
Genome 4.2 SP6 supports VS2012 RTM - Friday, August 24, 2012
Genome v4.2.7 provides integration to Microsoft Visual Studio 2012 RTM with the same functionality as for VS2010. This release contains only this tool enhancement and no change in the runtime.  
Genome 4.2 SP5 with VS2012 RC support - Friday, June 29, 2012
Genome v4.2.6 provides integration to Microsoft Visual Studio 2012 RC with the same functionality as for VS2010. This release contains only this tool enhancement and no change in the runtime.

Important note: Visual Studio 2012 RC comes with a change in the MsBuild system, that causes the Genome builds fail (in VS2012 and also in VS2010) with the following error:
error MSB4185: The function "CurrentUICulture" on type "System.Globalization.CultureInfo" has not been enabled for execution.

This problem will be fixed my Microsoft in VS2012 RTM. In the meanwhile you have to set the environment variable “MSBUILDENABLEALLPROPERTYFUNCTIONS” to “1”. (You might need to restart Visual Studio).
 

Genome 4.2 SP2 (v4.2.3) released - Oct 29, 2010
With many fixes and small features!   read more...
Genome 4.2 released - Feb 10, 2010
Supports now Visual Studio 2010!   read more...
Updated roadmap - Dec 22, 2009
learn more about the upcoming Genome v4.2 release   read more...
Genome 4.1 released - Mar 31, 2009
Read more about what's new in this release.   read more...
New Product Video released - Jan 16, 2009
Get a quick overview of Genome v4.   read more...
 
         
     
  Convincing your DBA  
 
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-related phobias
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.

Control-related phobias
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.

Security-related phobias
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.