Best practice using data types in data access layer?

Hot Topic

Help Required- List Events
DAO pattern
Application State in Web Farm Scenario
Design Consideration for active/active clustering
Sharepoint Services 3 - Document Page Not Showing
internationalization architecture
Migrate 2.0 to 3.0 on another server
User Control in Page Layout
Regarding Profile Manager fields having Null value
CAS Error

SharePoint Products

.net binary web services.
sharepint first website setup
Data Auditing Techniques in SQL Server
Bold Font or Image Bar in Left Nav? Can it be done?? if Yes, HOW?
ASP.NET Shapes in Visio
Design Question about an "actor" in a use case
Apprval workflow...
Cannot upload a .exe file to a sharepoint site.
uploading a site structure from database to sharepoint site
DB content migration from Sharepoint 2003 to MOSS 2007

Best practice using data types in data access layer?

Hi,

Well, couldnt quite find a valid group - hopefully this one will do.
Im using the web service factory application tool with great joy (http://www.gotdotnet.com/codegallery/codegallery.aspx id=6fde9247-53a8-4879-853d-500cd2d97a83). But i have come up short looking for best practices about using (or not using) data types in the data access layer.

The scenario:
I have some service call that in standard way gets data. Data access layer working on business objects and the service returning the translated data types. Now theres the need for paging results. Thus I create some usefull data types for Paging. In this case a PagingIn and PagingOut data type (eg. the pagingout would hold the total number of pages etc).

Now - is it "ok" to use these classes in the data access layer So that the dal would map SQL output directly in the data type "PagingOut" Or is it better to create business entities that can hold the paging data and then map thoses into the data types in the translation routines

Hopefully you get my meaning - in fact it could be extended to: If the business entities is 100% equal to the data type why bother creating the business entities and translations Any good reason why one should NOT use data types in the data layer as explained above

Thanks for any input...

--
Werner

Answer this question

Best practice using data types in data access layer?

  • ClaudiaHelpOnVSTO

    Hi,

    Yes they are. In this scenario the consumer has the requirement to specify paging. Like this:

    <s:complexType name="PagingInput">
     <s:sequence>
     <s:element minOccurs="1" maxOccurs="1" name="PageSize" type="s:int" />
     <s:element minOccurs="1" maxOccurs="1" name="PageNumber" type="s:int" />
     </s:sequence>
    </s:complexType>

    In context, the paging data types are available through the request and response objects if they contain a List that derives from a base-list type that defines paging.

    So the consumer could access say, " response.Cars.List.PagingInformation.TotalPages " to read the total number of pages from the response object.

    --
    Werner

  • j_o_h_a_n_n_e_s

    > As for the PageIn, PageOut classes do you mean how they look like code-wise

    Actually, I was curious about how/if those classes are visible in the WSDL.



  • Craig G

    I don't see any problem channeling SQL results into a generic container rather than a more strongly-typed collection. But I have a bias away from using stongly-type business entity classes -- so take that with a grain of salt. I prefer that the DAL simply manage the queries, connections, and concurrency for views of entities defined in metadata. The container that receives data from the DAL can be a strongly-typed or a generic collection. How are the PAGEIN/PAGEOUT classes described in your web services, BTW

  • PrashG

    Hi Erik,

    Thanks for your input. I think I have come to the same conclusion.
    As for the PageIn, PageOut classes do you mean how they look like code-wise If yes, I'll post them as soon as I get home from work where my developer-test-pc resides.

    --
    Werner
  • Best practice using data types in data access layer?
Answer this question