Would a ORM fit my purpose

Question

We usually write stored procedures on the database which accepts xml and returns result set as xml. I am thinking of providing a abstraction for the database calls like below

Example

    public List<Person> GetAllPeople()
    {
        string requestXml = "<Request><Type>GetAllPeople</Type></Request>";
        //execute a procedure with above xml as input
        //load the response xml into dataset
        //foreach record instantiate Person & add to list
        return List<Person>();
    }

so that the team can work with strongly typed objects rather loosly coupled Xml Strings. I think this is the work that ORM does right? Or should i code my own Data access layer to return objects rather than dataset and datatables. So the question is

• Will ORM suit this type of data access?

• What would right path to follow for abstracting database calls?

Specs

SQL Server 2005, .NET 2.0, ASP.NET 2.0, C# 2.0

Answer 1

Definitely devise a data access layer. This layer will be comprised of DAO classes, each class for accessing specific types of data (or objects, if its an OO system).

Now its up to you how you want to write this layer. You have several choices:

1. ORM.
2. Plain old JDBC
3. the stored procedure method you mentioned.

If you decide you want to go with ORMs, make sure what you're getting into. Build a couple of demo projects to understand how the ORM works.

Now, I'm a little skeptical about stored procedures, mainly because can do all kinds of stuff - both data retrieval, and logic execution. I avoid stored procs to make sure that all business logic is in my code (be tha tjava, PHP or other). For relatively small systems, I advise you to go with a simple SQL query based Data Access Layer.