ASP.NET Object Oriented Programing - Linked Object Reporting?

I'm developing an ASP.NET application, for the first time from the ground up. I've been doing web development for 4 years, but our shop is classic ASP based with a SQL backed. We've begun migrating to ASP.NET but we're not really using it to it's fullest because we're still doing the backend using SQL which just sends datatable to the presentation layer for rendering, meaning we're not using the OOP approach and propery 3-Tier design.

So now that I am going down this road, I have a question. Suppose I have two business objects that are related, e.g., a Customer and a Shipping Address. The customer has properties such as Name, Race, Gender, Age and the Shipping Address would have your commen properties such as Street Address, City, State, Zip, Country.

Now then, the Customer object also has a property called ShippingAddress which is obviously enough, a ShippingAddress object. When I instantiate my Customer Object, I am also instantiating a new instance of ShippingAddress and supplying all of it's field. This seems straight forward enough.

But now my dilema is this - suppose I have a shipping summary page that a list of every customer who has been shipped an order that day, but it's only display their last name and street address (no city, state or zip) and suppose this report has several hundred people on it. Because I do not need the extra overhead of the customers Age or Race and I also do not need the overhead of their Shipping Address' City, State, Zip - how do I go about supply this report with the correct objects?

Do I instantiate the objects as-is and do not supply those properties with data?

Do I instantiate the objects as-is supplying all day, incurring the overhead, but not rendering the data on the report?

Do I create a new object(s), that has only the data this report needs and instantiate those instead?

I have no formal training in OOP, and most peopel tell me there is no best practice for this kind of thing, but I'd have to imagine there are people who have ran into this before and I'd like to know what some of your solutions have been.




I understand what you're saying and the database does have a proper relationship model. I also realize that a customer may have more than 1 address and I would want a one to many relationship between customers and address, but for the sake of this example I was just using 1 to 1.

By dilema lies in that I don't want to bind a datable - returned from a SQL query - directly to my GridView control. I would prefer to bind Business Objects (Customer, Address) to the Gridview. I realize this may seem like overkill, and perhaps is, but I was under the impression that this is the way to go to ensure my web application is properly tiered into a presentation layer a BLL and a DAL.

Maybe I need to do a little more research and reading, I could be over thinking it as you've suggested. :)

2 Answers

  • Anonymous
    1 decade ago
    Favorite Answer

    You're making this a lot more complicated than it need be.

    Assuming you're a normal developer who has created the type of tables that are common, you have a table that contains customer names and perhaps a table that contains address information.

    The address table has a foreign key that relates to the customer table's primary keys: That is, customer record 1 may have three or four addresses, but each of those address records has a customer key of 1.

    In the order table, each order record need contain two foreign keys -- one for the customer id, the other for the shipping address id.

    Then, when you want to create your report, you simply supply a SQL query that gives you the appropriate fields, e.g.:

    SELECT c.last_name, a.street_address, FROM orders AS o INNER JOIN customers AS c ON o.customer_id = INNER JOIN addresses AS a ON o.shipping_id =

    And, provided you have properly keyed everything, you only get what you want.

    That said, you can work with more complex objects using the ADO.NET Entity Framework.

    Again, I think that's huge overkill, given that the traditional approach works fine, but it is an option.

  • Anonymous
    4 years ago

    because of the fact C++ is purely too effective for it is very own sake. With C++, you're able to make a application that's merchandise oriented, even yet it is likewise a possibility to make non merchandise oriented application in C++, like procedural. perhaps it is the case that makes it not seen organic merchandise oriented, on the grounds which you're actually not forced to create merchandise oriented application. you additionally can combination up merchandise oriented and procedural in C++.

Still have questions? Get your answers by asking now.