The Object Dilemma

[maramusa]

This must be a time old question to do with Modularisation, encapsulation and RE-USABILITY.

I have an asp.net 3.5 vb.net intranet application.

I have a Job class. i have a Client class and employee class etc etc
I am using the dataset designer, and formviews.

I have a formview for my Job object. A job has a clientID. But in my formview, when i display a job, I want to show the ClientName obviously. This can be done in the formview Edit Template, by linking the ClientID field to a datasource (or object datasource)that has the Client table, the a simple INNER JOIN to get the ClientName. Easy, no code, nice.
But I dont want to have to go to the data access layer to get the ClientName. I want to be able to call the Client object like Client.Name.

I guess I could do this with a Webservice (or WCF which i havent used yet). But this seems like a big overhead using SOAP and HTTP just to get a ClientName with an INNER JOIN. We have 100 users and the clientname will be getting accessed all the time.

I guess I could use a stored procedure, but how would I link this to my Formview to show the ClientName. When Editing or Inserting a JOB, I still want the user to be able to select the ClientName form a dropdown which is linked to ClientID. So I still need a datasource right.

LINQ ???, but

I want my Client object to be in a separate application, that any other application can access, so no need to redo the DAL everytime. Yes, Im trying to do a framework.
If the Client object has fucntion that require logic, these i would obviously use a webservice or WCF, but for simple INNER JOINs and stuff, I'm stuck at the best way to be able to call these form any other application in formviews or the like.

Thanks for any ideas

 

[jmcilhinney]

You say that you're using the DataSet designer. Just edit the Job DataTable to include a ClientName column and then edit the query that retrieves the data to join on the Client table and return the ClientName column. When you retrieve Job data from the database it will now include the ClientName but saving Job records will remain unchanged, so the ClientName won't affect that part. What that does mean though, is that it's up to you to set the ClientName field of any new Job rows that you create in code for yourself. That's a simple matter though, as it's just one extra line of code where you set the ClientID.

 

[maramusa]

Thanks for reply

Thats how I am doing it at the moment, I have a subquery in my Job datatable that does the INNER JOIN to the Client Table. yes its very easy and quick.
but that still means my Job Application is doing the data access for ClientName.

I want ONLY the Client object to do the data access layer for ClientName. If the Client table changes, then I dont want to change code in other objects(applications) like the Job.

Sooo, I want to call the Client Object from Job, ...i guess my main question is how do i call the Client Object(application) that is separated form Job. If i use a Webservice or WCF , isnt that a lot of traffic and maybe too slow just for a simple INNER JOIN.
Maybe the GAC would be better? but I do want to keep it simple.

 

[jmcilhinney]

The way you have it set up you have two choices:

1. Do what I suggested and make one trip to the database.
2. Don't do what I said and make two trips to the database.

As you've said that you don't want to do what I said, which is fair enough, then you need to make two trips to the database. Their really isn't a middle ground.

If you were to use an ORM tool then that might change things a bit. I've only used the Entity Framework myself and in that case you can do something like this:

Dim firstJob = entities.Jobs.Include("Client").First()
Dim clientName = firstJob.Client.ClientName

By specifying the query to include the Client related to the job you will ensure that the Client property is populated. Without the call to Include the firstJob.Client property would be Nothing. I'm sure there are similar facilities using SubSonic, NHibernate, LLBLGen Pro and the like but I've never actually used any of them myself.