views:

145

answers:

5

Im having a really hard time figuring out how to specify a good search term for my problem: separation of gui and database interaction in visual studio 2008 using Linq to sql.

According to my teacher in a c# class im taking it's not correct to let the GUI be dependant on a specific way of getting data.

The way my project is currently set up is that we have a mssql database where everything is stored. The solution is split into 4 seperate projects. UserGUI, AdminGUI, Logic and Db.

Now using linq to populate listboxes and similar things I use something like:

From the windows form in the project UserGUI:

//The activeReservationBindingSource has Db.ActiveReservation as it's value
private void refreshReservation() {
            activeReservationBindingSource.DataSource = logic.getActiveReservationsQry();
        }

To the Logic project:

public IQueryable getActiveReservationsQry() {
    return dbOperations.getActiveReservationsQry(this.currentMemberId);
}

To the database project:

public IQueryable getActiveReservationsQry(int memberId) {
            var qry =
             from active in db.ActiveReservations
             where active.memberId == memberId
             orderby active.reservationId
             select active;

            return qry;
        }

This makes sense to me seing as I can send items from listboxes all the way to the database project and there easily update/insert things into the mssql database. The problem is that it would be pretty hard to merge over from a mssql database to lets say an access version.

What should I be reading up on to understand how to do this correctly? Is creating my own classes with the same values as the ones visual studio generates for me when I create the dbml file a way to go? Should I then in the logic project populate for example List that I pass to the GUI? To me it seams like "double work" but perhaps it's the correct way to go?

Be adviced that we have not read anything about design patterns or business logic which seems to be a pretty big subject which im looking forward to exploring outside the frame of the course at a later time.

I was also thinking that IQueryable inherits from IEnumerable and perhaps that was the way to go but I have failed to find any information that made sense to me on how to actually accomplish this.

The GUI also knows about the datasources which I think is a bad thing but can't figure out how to get rid of.

Please understand that I tried to figure this out with my teacher for half an hour today at the only tutoring available for this project and then spent most of the day trying to find similar answers on google, SO and from classmates without any result.

A: 

Check out the repository pattern. There are several implementations you can find by googling "Linq repository."

you may want to check out the MVC Storefront series here: http://www.asp.net/learn/mvc-videos/#MVCStorefrontStarterKit. In the series, Rob Conery builds a Linq IQueryable repository that returns custom made objects instead of the linq objects.

Daniel Auger
A: 

One keyword to read up on: Model-View-Controller. That's kind of the idea you're after. Your "View" is the GUI. The "Model" is the data layer, and the Controller is the code that takes data from the DB and hands it to the GUI (and vice-versa.)

taylonr
+2  A: 

There's a post here that I answered where the question was a bit similar to yours. I think it worth to take a look.

Regards

Andres
A: 

According to my teacher in a c# class im taking it's not correct to let the GUI be dependant on a specific way of getting data.

Honestly your teacher is an idiot. This is one of the stupidest statements, from a database perspective, I've ever read. Of course you want to be dependant on a specific way of getting data if that is the most performant way to get the data (which is almost always database specific and means not using LINQ to SQL for complex queries but that is another who issue). Users care about performance not database independence.

Very few real world applications truly need to be database independant. Yes a few kinds of box software sold commercially are (although I think this is usually a mistake and one reason why every commercial product I've ever used is badly designed and horribly slow).

And since every database implements SQl differntly, even using ANSII sql is not completely database independant. Access in particular is no where near close to the ANSII standard. There is no way to write code which will work correctly on every single possible database.

HLGEM
A: 

May be you can take a look at Data Abstract

Hugues Van Landeghem