5

Quoting the answer of Andrew Hare on the This Question.

Object data sources are nice for small projects but they do not scale well as you are embedding data-layer information in the UI layer of your application. I would suggest that you only use them for very small applications and scratch-pad testing stuff. If you make a design decision to use them be prepared to struggle with scaling and maintenance issues in the future.

Application Architecture = Maintainability + Scalability + ......

And I think, every article that I've read to start learning application architecture used some classes to build up the business data layer and used ObjectDataSource to connect the presentation layer with the business layer.

Looks like I've got all wrong. What's really the best approach to use for the business layer and its connection with the presentation layer?

Community
  • 1
  • 1
Mazen Elkashef
  • 3,430
  • 6
  • 44
  • 72
  • Good question. I've seen myself different approaches. Personally while building a specialized sales module I've tried two approaches - pure ado.net and object source. The second one provided more flexibility and reduced the amount of work needed do get the job done(about 75% of it). The worst thing that was with pure ADO.NET was managing the db code (I had about 60 tables + many stored procedures that I had to change every time sth. was changed in the schema. not ever again! ) – kubal5003 Dec 20 '10 at 00:33
  • @kubal5003- Thank you...but isn't ado.net and ODS two tools that complete each other ?...I mean I query my database with pure ado.net and sql, and send the information to the business layer as a List<> and the BLL send it to the asp.net pages using ODS....N.B I noticed that it's fast and easy, specially for implementing sorting and such functionality but I'm talking scalability and a strong structure, sadly nothing of those goes with Fast and Easy! :) – Mazen Elkashef Dec 20 '10 at 00:40

2 Answers2

4

There is no doubt that ObjectDataSource makes the binding process easier.

It handles filtering, paging etc..with less headache.

Points to be considered.

  • View(.aspx) has reference to the Business object so it restricts some of the tasks like Refactoring while the application grows bigger.
  • Many application nowadays use IoC and ODS does not support that.
  • ODS works on parameters and if filter conditions increase we have to increase no. of parameters in the Business which is also not desirable.

So if we consider all these points ODS does not scale well.

dhinesh
  • 4,676
  • 2
  • 26
  • 44
  • 1
    +1 Finally some good reasons!...well dhinesh, what is our alternatives or how do we build a scalable applictions ? – Mazen Elkashef Dec 25 '10 at 13:09
  • 1
    You're really providing the best answer for this question, But I hope you could share a scalable alternatives for ObjectDataSource. – Mazen Elkashef Jan 03 '11 at 18:04
2

I don't use the ObjectDataSource; personally, I like the control over the binding process, so I bind directly through the DataSource property, and not use the DS controls. Because the DS controls when to bind or not bind, I dislike tapping into events to cancel binding only because I didn't want to do it at that specific time... It can mask some types of coding blunders, making it harder to debug, but if there is an error, you can tap into the selected, inserted, etc. event and handle the error, I believe.

However, I don't see why its wrong; I am not quite sure why it wouldn't scale well... if it works for you, and when you test the performance is OK, then why not I would say.

HTH.

Brian Mains
  • 50,520
  • 35
  • 148
  • 257
  • Well, I used to do everything in the code-behind and I didn't even use the Text='<#% Eval("Field")%> approach, I assigned the values from the code-behind but I don't know why people said it's a bad practice! :S do you think it affects the scalability or the secuirty of your applications ?...and how is it possible to test the performance -specially on the development local machine- ? – Mazen Elkashef Dec 20 '10 at 10:34
  • It would affect security the same way you invoke the method; security can be handled. Scalability, I'm not sure why that comment was made,I don't see why. Performance testing - like any other code, create sample apps, and performance test using tools like Red Gate, or MS has some tools (haven't used them). – Brian Mains Dec 22 '10 at 02:32
  • From peformance, at bare minimum if user is OK with performance, that is the best benchmark :-) – Brian Mains Dec 22 '10 at 02:32
  • @Brain- Thanks for the help. but I didn't quite get what you wanted to say about security. and about Red Gate, do you mean "ANTS Performance Profiler" ? – Mazen Elkashef Dec 22 '10 at 11:05
  • ObjectDataSource instantiates a component and calls a method. If that method lets the user do what they aren't supposed to do, using the ODS vs. calling the method directly is the same thing. So I don't understand how the ODS circumvents security since it does the same thing as you calling the method directly. If a method returns 20 records, 10 of which the user isn't supposed to see, the issue isn't the ODS, but the code :-) – Brian Mains Dec 23 '10 at 01:52
  • Yes,ANTS Performance Profiler, or EQUATEC. Latter is free, but not used it much so couldn't tell you more about it. – Brian Mains Dec 23 '10 at 01:53