I would like to know what the best approach is when using entitycollections or typedlists or views through wcf.

I am researching this solution/situation- 1. Database tier (oracle) 2. Dal/BLL tier (LLBLGEN) -> WCF service 3. Client tier

Client makes a request for data to the WCF WCF fetch the data (oracle) Sends back to client

I already have this set up and it works fine. But what if we are talking about tons of records/fields? How will this perform with 100 users doing constantly these datarequests? How can i architecture this in a fine/neat/fast way?

hope someone can give some tricks/hints/..

Richard

As ever with these sort of questions, there are almost two many variable for us to give a sensible answer...!

Some general thoughts.

1) Limit the number of rows and columns returned to the users. Users filters and paging to reduce the number of rows, and only return the columns they need to see. Use TypedLists, TypedViews and DynamicLists for building list forms, only use EntityCollections when needed.

2) Your architecture looks sensible - make sure that you build it so that each layer can be on a server on it's own if you need to build up for scalability.

3) 100 users is not a lot. In the typical line of business/CRUD app most uses spend most of the time staring at the screen, not requesting or updating data. Modern server hardware should cope with this without breaking a sweat

blog.stackoverflow.com has some good blog entries about the sort of hardware that they use to support one of the busiest developer Q and A sites on the web - worth a read.

Matt

MTrinder wrote:

As ever with these sort of questions, there are almost two many variable for us to give a sensible answer...!

Some general thoughts.

Thanks Matt 1) Limit the number of rows and columns returned to the users. Users filters and paging to reduce the number of rows, and only return the columns they need to see. Use TypedLists, TypedViews and DynamicLists for building list forms, only use EntityCollections when needed.

This is what should be possible in theory. That a user selects all possible fields to display And queries all records. Is there a sort of loadondemand-feature? 2) Your architecture looks sensible - make sure that you build it so that each layer can be on a server on it's own if you need to build up for scalability.

It is built that way. Imagine a databaseserver, centered in the country I'm thinking about of installing several WCF-Hosts (this can be anywhere) which communicates with the database The client then commivates through one of these hosts.

3) 100 users is not a lot. In the typical line of business/CRUD app most uses spend most of the time staring at the screen, not requesting or updating data. Modern server hardware should cope with this without breaking a sweat

blog.stackoverflow.com has some good blog entries about the sort of hardware that they use to support one of the busiest developer Q and A sites on the web - worth a read.

Matt

And queries all records. Is there a sort of loadondemand-feature?

There is - take a look at the paging feature. Having said that, it's very rare that users don't know enough about the data they are querying that they can't find something to be able to filter it on - returning more than a few hundred rows to a user is usually pretty meaningless.

Matt