Question

question:
i’m building (or trying to build) a front end for an enterprise level web-app. the existing structure is driven by stored procedures (sql 2008 db). A stored proc is implemented as a class that ultimately handles the execution and the results are returned as an object.
i’m new to this game and would welcome an explanation about how my time would best be served…i read a repository pattern is a best practice, but all of the examples i read implement Entity Framework or Linq, etc..do i need an ORM? why or why not? i’d like to be able to have a maximum performance environment so that users can play with those result sets. thanks in advance

Answer 1

Well, I would suggest deciding on your use cases.

Some of the things that nHibernate / ORM’s generally are not good for are:

1. Batch jobs.
2. Reporting

So if your work primarily involves either of those then you’re best off not wasting your time, that being said there’s nothing wrong with having multiple strategies… Building out a domain model is great for simplifying complex business rules, performance is generally very good too… Reporting and batch jobs can be built out separately, there’s no reason why the different strategies can’t co-exist… I woul however do my best to keep them decoupled…

So if you’ve got a big hairy business logic layer and it’s littered with datasets / data access code and business logic IN your stored procedures then you will likely find it worth your while to invest in an ORM, but consider it a re-factoring step… IE you’re improving existing code and making it testable before extending it…

In any case there’s no one ‘best’ answer, the smartest thing I’ve done at previous companies has been to build new functionality (Test driven of course) in whichever data access pattern that seems to make sense to the functionality… Keep interfaces clean and decoupled… After doing that for awhile it usually becomes obvious which strategy / pattern is best suited for the application overall…

Good luck