The Object Dilemma RRS feed

  • Question

  • User-746782185 posted

    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 Im still doing the data access

    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

    Wednesday, October 21, 2009 2:16 AM


  • User-952121411 posted

    I read your post thourghly, and hopefully I understood it properly to provide this solution.  What you could do is extend the Job object to have a property that is of the Client object type.  A lot of times the method of having more complex types like objects as properties rather than just String, int, bool, etc is overlooked or occassionally required to serialize objects.  However, in your case it sounds like this could be a good solution.

    If there is a 1:1 relationship between Job and Client, then the property on the Job object will just be a single instance like below:

        Private mClient As Client
        Public Property ClientObject() As Client
                Return mClient
            End Get
            Set(ByVal value As Client)
                mClient = value
            End Set
        End Property

    If there is a 1:many relationship between Job and Client (a job can have multiple Clients), than a List(of) objects as a property will be more appropriate:

        Private mlstClient As List(Of Client)
        Public Property ClientObjectList() As List(Of Client)
                Return mlstClient
            End Get
            Set(ByVal value As List(Of Client))
                mlstClient = value
            End Set
        End Property


    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, October 21, 2009 9:11 AM