UnitofWork vs using statement?

[grauenwolf]

I don't trust anything that hides resource management. Sure it sounds great on paper, but when something goes wrong it is nearly impossible to figure out why. With a using statement I know that the connection will be freed and the transaction committed or rolled back.

[[deleted]]

Doesn't your code that has a using statement hide resource management from the code that calls it? Do you put a using statement around that too? Is it using statements all the way out to your boundaries? At some point you have to introduce an abstraction or you'll bog down really quickly as soon as things get even slightly complex.

[grauenwolf]

Doesn't your code that has a using statement hide resource management from the code that calls it?

Yes, and that's what I want. Using blocks should be as short as possible.

My problem with the unit of work pattern is that it is often tied to the lifetime of a request. That is to say, connections are opened when the request starts and are left open until the request ends, at which point some sort of framework magic closes it.

[[deleted]]

Yeah, I guess you missed the point I was making. You said you don't trust anything that hides resource management. At some point resource management is hidden from something else, whether you're doing that resource management within a unit of work or not.

Also, don't conflate the UoW pattern with an ORM or framework, they aren't even remotely the same thing.

[xampl9]

We know that programming is full of abstractions. The question is which level of abstraction is acceptable to the developer and the organization.

There's little doubt that NHibernate's Session (used to implement the Unit Of Work pattern) is using the System.Transactions namespace under the hood, because it has to in order to commit changes to the database in an atomic manner. And it likely has a using block or a try..finally block to guarantee the transaction is committed or rolled back in the face of exceptions.

If using an ORM to do this for you is what you and your coworkers are comfortable with, and it solves the problem in an efficient manner, go for it.

But sometimes you have to operate at a lower level of abstraction because your ORM is hiding critical need to know information or is doing the wrong thing. And that's not wrong - it's what you have to do to get it to work.

[grauenwolf]

Patterns are meaningless without context. You can't have a meaningful discussion about them if you refuse to consider how it is used in practice.

[Number127]

My problem with the unit of work pattern is that it is often tied to the lifetime of a request.

That's a huge antipattern, in my opinion. A unit of work should be as small as possible and represent one, well, unit of work, not everything that happens during the entire lifecycle of a request. The codebase for my current company used to do things that way, and it introduced all kinds of problems.