Orm tool not allowed: What do you do?

Question

Let's say you're in an IT shop that allows no ORM tool of any kind. They don't want to buy one, and neither can you use an open source solution.

What would you do? Give up on a real domain model and work table-centric? Craft own DAL?

Answer 1

Options:

1. Roll your own
2. Quit
3. Use an open source one anyway without telling them, show them the prototype when it's working well, then ask them to reconsider open source.

Answer 2

I'd roll my own DAL, using something along the lines of Generic DAOs to abstract it in such a way that the rest of my code isn't tightly coupled with however I'm getting to the data.

That makes it easy to swap it all over to an ORM if they come around later.

Answer 3

Craft your own DAL, like we did in the beforetime, the long long ago... 2004.

Answer 4

Ask why ORM's are not allowed, what constitutes as a ORM, and then decide from there 1 of two possibilities:

1. Deal
2. No deal ( quit )

Answer 5

Strictly speaking your options are:

1. Don't use a relational database
2. Don't use an OOP language

Otherwise some kind of ORM solution is inevitable (even if you roll your own, its still a simple ORM layer).

Answer 6

First, of all I will find the REAL answer for the question "Why open-source ORM isn't the case?"

If this is because of person who have made this decision 1)have a fear in perfomance slow-down - will prove, that there won't be a problem with it. 2)if it is because of fear that "we can't afford one more tool, because the system is already complicated" - will explain, why ORM will speeds my speed up.

I think that other decisions(table-centric coding, own DAL) - aren't beautiful solutions. I think, that if you are not allowed to use ORM for your job - I don't know.. I would leave such project, if I were you.

Answer 7

First off, it's absolutely retarded that you can't even use an open source one.

If you have to roll your own, it's not a huge deal. You can still have domain models just fine. You might have an easier time if you model each record, and then build the domain models to load data from that as an intermediate format.

Answer 8

There are three possibilities here:

1. Your bosses don't understand the benefits of using an ORM.
2. Your bosses are doing things the way they always have done things and won't consider changing.
3. Your bosses have valid reasons for not choosing an ORM.

More than likely though, it's a combination of these three things. They probably have valid concerns that could be cured through better understanding of ORMs. My advice is to try selling them on ORMs. Find a particularly nasty piece of code that could be cured by using an ORM and make a prototype that shows how much that code could be simplified. Also, be willing to compromise.

If they're not willing to budge on this, you need to ask yourself if this is really a place you want to work. Not because they won't let you use ORMs (which you could probably live without), but because they won't listen to you. You can't always have your way, but you should have input on the development process.

Answer 9

If it's about the company being too cheap to buy one, then write your own, and at the end of the project show them the cost in terms of your time. (I assume they're against free alternatives on principle)

If it's about performance, you might have to check whether they have a point.

If they worry that it adds a layer of complexity which other developers will have to learn, then show some examples of code simplified with the ORM.

If it's because the application is already very "table-centric" you'll also have to think whether adding an ORM will improve things or just add a lot of unnecessary mapping complexity.

(Oh, and read this : http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx )

Answer 10

Based on your username, I'd say "use LINQ." It's built into .NET and it's not an ORM (strictly speaking).

Answer 11

See what they think about iBatis (http://ibatis.apache.org/) which isn't an ORM but helps you get objects from database queries without inscrutable ORM magic, lots of XML though.

How are they doing things now?

Answer 12

If you truly cannot use one of the existing ORMs, then I do not advise creating your own. Locally grown ORMs tend to be half-implemented, poorly-designed, wart-ridden beasts that appear to help for the first six months, then gradually become the biggest time-sucks on the project.

You can do without an ORM if you apply patterns like "RowDataGateway" or "TableDataGateway" from Fowler's Patterns of Enterprise Application Architecture.

You'll still end up growing your own isolation layer to separate your domain from the database, but it won't be as expensive to create as rolling your own ORM.

Answer 13

"no ORM tool of any kind. They don't want to buy one, and neither can you use an open source solution."

No ORM any kind OR just open source/$$$?

There are free versions of great ORM tools:

• Telerik Open Access Express: works with Express databases
  • Web: http://www.telerik.com/products/orm.aspx
• Lightspeed Express: limited to eight model classes
  • Web: http://www.mindscape.co.nz/products/LightSpeed/download.aspx

Answer 14

I would roll my own solution, probably using some kind of code generation tool. Tecnically if you translate the results (be it datareaders, tables, recordset or whatever) to your objects you have a small o/r mapper, very lacking but still... It is a matter of definition I guess.

My primary goal would be to avoid repeating CRUD in my code, it takes time, is boring and is a source of defects.

As stated: if a relational database is not required you could always go with some object database. But thoose are far more uncommon and if your boss is against orm:s he is unlikely to go for that.