How to encourage myself to switch to ORM?

I'm working with a legacy project of my team-mate (.NET/Oracle). The project is not yet completed, it's under construction and far from production. He foll开发者_开发技巧owed a "traditional way" to access data, which is creating stored procedures and then use database driver to call them. I want to follow a "modern way" to access data: use an ORM to abstract and access data. The switch will not cost much, in terms of time and money. The problem is, he is much more experienced than me, and he's kind of hate ORMs (he didn't explain why, but he said that it's confusing). I'm on my own now, but i'm not encouraged enough to switch to an ORM.

Then, should I switch to an ORM or not? if yes, please encourage me.

EDIT: I don't know why someone need to close this question. I'm not encouraged enough because I'm not sure which way is better. You can convince me, that ORMs make me develop faster, less errors, or stored procedures are faster,... whatever. I want to ask from you, which are, IMHO, experienced programmers (than me, and also my team-mate). My team-mate got his reason to use stored procedures, and many programmers have their own. I need to know why they think that (stored procedures are considerably good or they just want to use something similar with them, etc...)

Thank you so much.

Here are three reasons not to to switch:

1. Oracle PL/SQL is a complete programming language. It's not just some frozen SQL statements and some conditional programming. So it is quite likely that the PL/SQL layer contains logic which cannot easily be implemented in ORM.

2. Notoriously Oracle database licenses are expensive. The best way to maximize ROI on them is to leverage the built-in features. This is harder to do with an ORM tool, sometimes flat out impossible.

3. You describe your application as "legacy" which suggests it is in production. If so, changing the data access architecture would be a gross indulgence. You and your co-worker will spend a great deal of time writing code, not to mention regression testing for the entire application, with no discernable benefit to your users.

ORMs aren't "modern", they are intended for minimizing interaction with the database to the point you often don't have to write SQL. Which is also what you get by using SQL stored procedures & functions, assuming you have a database developer on the team to devote to the development & maintenance.

It's increasingly common in ORMs to support native SQL because they have understandably limited capacity to handle complex SQL. People have problems with SQL development, I don't expect software abstraction to be any better...

The "traditional way" is more targetted, making it more efficient to perform faster than with an ORM. The benefit of the ORM is to support multiple database vendors without the knowledge of the intricacies of each vendor, or SQL itself.

I would learn ORM for the possibility of employment, best served by knowing when to use it.

From your own words:

• Your team-mate is much more experienced
• You have to come here for arguments for the discussion
• Your team-mate allready has a working solution
• You have a looming deadline

Besides the technical arguments, I personally wouldn't dare to start a discussion about changing the data access layer based on these facts. Talk to your co-workers about using ORM in a new project. Don't be a pain in the neck during a running project by starting discussions about fundamental discissions that allready have been taken.

Switching to an ORM at this point is the action of a spoiled child and if you did it on my team without my agreement in advance, I'd fire you. There are many valid reasons to use stored procs including not allowing data access at the table level which is critical for financial systems for instance. Wanting to use some other tool because you want to learn it is childish and unprofessional.

ORMS are not better for many complex issues, they often create poorly perforimng code when things get complex. Stored procs can more easily be performance tuned which is critical. Stored procs offer better security for your data because you can limit the direct access to the tables and only allow the users to so the tasks that the porc has defined, reducing the possibility of fraud. It is also much, much easier to refactor the database if all the queries are in stored procs. Changes to queries are easier to apply as well, much easier to load one changes stored proc to prod than to recomplie and reload the whole application.

The time to desicuss tools to use is at the start of the project not inthe middle. A project where some is done in an ORM and some is done in stored porcs will become a nightmare to maintain.

It depends on what language you are most comfortable with and what platform you are developing for. Based on that criteria, I would recommend learning an MVC framework that forces you to use good ORM practices. In that space, Ruby on Rails (Based on Ruby) and CakePHP (Based on PHP) are great for web development. Although less strict on the ORM side, the ZEND framework is also very good if you like PHP. If you are working with MS SQL Server or are developing for the desktop, .NET MVC is the way to go, and this is compatible with any .NET language.

These frameworks will force you to adhere to good coding practices and you will wind up with better code because of it. They also automagically abstract the database schema, creating objects and methods to interact with the data. The learning curve may seem like an uphill battle at first, but once you learn the concepts, the fundamentals of the language kick in and you become a super-programmer!

There's also the added advantage of rapid application development (RAD). It's really easy and fast to get a working application up and running with most ORM frameworks. They can save a lot of time in the development life cycle.

I've split the difference in the past by using the (apparently now gathering dust in the attic) ultra-lightweight mapper iBatis, some extra attributes in the iBatis query definitions XML indicating single/multiple result set behavior, and an XSLT stylesheet that reads in the query definitions and spits out source code for a nice neat DAL class.

With this approach, you can plug in either stored procedures or direct SQL. You do miss out on some of the nicer features of cutting-edge ORM such as LINQ support and in-memory cache, but you also have a lot less trouble coping with 80/20 rule deviations that tend to be present in a schema that wasn't originally built with ORM in mind.

SPROCS are never a good idea in my opinion.

• PL/SQL is rarely, and often never, tested automatically. It may work when you implement it but without unit tests, how can you be sure that it will continue to work in the future without regression tests. A practice that I feel everyone should adopt is TDD. With discipline, TDD will not allow code to be written that is not automatically tested every build for regression problem. Don't get me wrong, I don't suggest you should go and TDD your PL/SQL (I know this is technically possible). I suggest you keep your code in your code-base.
• PL/SQL does not facilitate simple debugging. It is possible to step through your SPROCS but not by conventional application debugging means (especially not .NET to Oracle; maybe .NET to MS SqlServer).
• Using Database engine specific logic binds your application to not only that DB vendor, but that version of the DB and, quite often, that version of the DB driver. I have been on a project that used .NET and MS SqlServer and it was originally implemented with many SPROCS. The customer eventually said that they were unwilling to pay SqlServer licensing costs and wanted to switch to a open source DB engine (MySQL to be specific). We were unable to meet this request easily and that is just unacceptable when there are so many frameworks out there that easily facilitate switching DB engine at the drop of a hat.

That being said, there are the benefits of database logic tat have already being pointed out like optimized performance, utilizing existing Oracle licenses to their full benefit, and the complexity of switching over an existing application. I would never start a new project with anything other than an ORM but it is no easy job migrating an existing application over. In the end you will have to weigh the pros and cons and make an informed decision that would justify return on investment.