CODEWITHSUNDEEP
c#sql-servervb.netlinq-to-sql
user57630
user57630

Reputation:

How can I transfer LINQ to SQL results to an external dll?

Before LINQ I would have my main application return the results of a SQL query into a dataSet. I would then transfer the dataset as a parameter to the external dll. Now I am bringing through a LINQ to SQL query that is returned as an IQueryable(Of vClientTable) object. I want to be able to transfer that set of vClientTable results to my external dll in order for the dll to work with the data included in the results.

I am probably doing it all wrong as well as trying to do it all wrong, but would like some advice on what would be the best method to use.

DB Query

Public Shared Function getClientData(ByVal clientID As Int32) As IQueryable(Of vClientTable)
Try
    Dim r = From p In dbLINQ.vClientTable _
       Where p.ltClientID = clientID _
       Order By p.cdCode _
       Select p
    Return r
Catch ex As Exception
    Return Nothing
End Try
End Function

App Sub that retrieves the Data through the DB Query

Dim recordData As IQueryable(Of vClientTable) = getClientData(clientID)

Call to External DLL sub

dataComplete = outputClientData(Now, recordData)

DLL sub

public static Boolean outputClientData(DateTime rptDate, IQueryable<vClientData> clientData)
    {
        //Do something with the data
        return true;
    }

Obviously in the external dll it has no idea what an IQueryable(vClientData) object is and even if I create a dbml file and datacontext in my external project for the dll that includes the same class to the DB table/view it still says that the objects are different types.

Any ideas how I should be proceeding with this?

Thanks

Upvotes: 1

Views: 424

Answers (3)

Marc Gravell
Marc Gravell

Reputation: 1063774

Can the external dll reference the assembly with the entities in them? Then you can return any collection/set/whatever of your types. That is the simplest use.

I would, however, tend to avoid exposing IQueryable<T> on the API, since it is very hard to guarantee full support for all operations, and hard to guarantee that the caller doesn't break your DAL (accidentally or on purpose); I would have discreet operations that return known constructs such as List<T>, T[], etc.

If you can't add a reference, then other options include:

  • serialization (this is essentially how WCF transfers such objects; just enable serialziation on the designer surface, and use DataContractSerializer; you will need a matching data-contract at the other end, but it doesn't have to be the same type)
  • transfer into a known type such as DataTable - a bit like this and this, although I'm not really a fan of DataTable
  • expose it as object, and use reflection (ho-hum)

Upvotes: 0

Lazarus
Lazarus

Reputation: 43094

My first reaction here would be to abstract the data access layer into it's own assembly and to give both your application and your DLL references to it. This would allow you to reference the vClientData class in both as it's only that which you need to share.

Upvotes: 0

Joseph
Joseph

Reputation: 25523

I'm assuming that once you get to your external dll that your IQueryable would have had it's context closed, so right there you have a problem. If you try to enumerate through the result set you could get an exception since it's most likely that the context has already been disposed. FYI, the context is basically the thing that connects your IQueryable to your database.

As for what to return, I would suggest starting by returning an IList first, instead of an IQueryable. You can do this by calling .ToList() on your IQueryable, and then you would have an

IList<vClientData>

This should at least get you started in learning how to get around with LINQ. Learning how to properly use the IQueryable construct is going to take some practice and learning, but pushing the result set out to an IList or array of some sort should get you on your way.

Upvotes: 0

Related Questions