locked
Extraneous transferred entity data RRS feed

  • Question

  • My current solution (.NET 4) includes a Web Application, EF generated model (Self tracking POCO), EF generated persistence context, and a WCF Service. The Web Application makes requests to the WCF service which then uses LINQ to EF to perform various tasks relating to news items. A news item is simply defined as an entity in the model with the following properties: Id, Headline, Date, Body. On the front page of the web application I'd like to display the 10 latest news items. Technically this is easy. Just make a request to the WCF service's GetNewsItems method and it returns a List(of NewsItem). The problem is I'm only going to use the Id and Headline on the front page. The Body property (largest) of the NewsItem is then being unnecessarily transferred over the service. The options I see are to separate the NewsItem into NewsItemHeader and NewsItemDetails entities. I'm not fond of this though because of the extra complication and undoing of the whole Entity concept. The other option is to populate the NewsItem properties selectively, leaving the Body property "" or NULL. However this creates ugly LINQ while it still seems strange to have an entity randomly missing properties. What is one to do? In a single layer application this would easily be solved by just including a bit of T-SQL to get the columns in question, but of course that comes with its own maintainability issues.

    I assume this is a very common architecture. Am I correct?

    The more I learn and try to follow good architecture design principals and separate concerns into layers the more problems there seems to be in the reality of it. It seems there are a lot of good theories, concepts, best practices, etc. out there that make sense at first and sound great but then turn out to be difficult to actually implement in the real world. It's no wonder so many people have T-SQL in their "OnClick" events.

    Thank you for your time,
    Eric
    Wednesday, March 17, 2010 10:37 PM

All replies

  • I suppose the general question is: What design pattern is best used when you need only a few properties of many business objects?

     

    Thanks,

    Eric

    Friday, March 19, 2010 6:38 PM
  • It's a different type, so a different class.

    If you have the data stored in some persistence layer then you want a layer on top of that which decides to pull out the 2 properties or the whole lot or goes and gets it via linq or whatever.

    Your problem is significantly simpler than it could be, since you don't have to update the data.

    Friday, March 19, 2010 6:52 PM
  • Actually in the case of NewsItem(s), a NewsItem may be fetched, updated, or deleted. The problem scenario is when you need to display a list of NewsItems using just their Id and Name properties. To take things further, what if in general you have an entity with 10 properties and there are many cases in which you may need only 3, 4, or 5 different properties? This must be an extremely common issue because it's such a fundamental need, but I haven't seen anyone addressing it.

     

    Thanks,

    Eric

    Friday, March 19, 2010 7:19 PM
  • Typically you would want to use DTOs (Data Transfer Objects) for requests and responses from services.  This will allow you to maintain your entities in the business layer, but transfer only the required data to the invoking application.  The real issue comes when you realize you might have two different consumers for your service, and one might be interested in more data than the other.  The idea is that you in fact want to make your DTOs generic enough where they would contain sufficient data to serve any consumer.  This is obviously comes at a cost of performance to some degree, meaning you might return more data in the response DTO than a caller is interested in.  If performance becomes a real issue, then perhaps in your request DTO to the method you can set a flag that signals the service "hey I want all the data" or "hey I am only interested in the slim response".  There is never a magic bullet, typically all of these architectural best practices come at some cost :)
    Saturday, March 20, 2010 4:46 AM
  • If it's a problem then you have another layer and hand over different types or a variable type.  If it's not a problem you hand over the lot and the view picks what it wants.  IME there are few instances where one entity is presented with numerous variations in number of columns AND performance matters a lot.  Usually multiple variations are a data mart or reporting issue where you have a type per report + maybe per header. 

    If a newsitem (or whatever) can have 36 columns then how can you insert with 3?  If the rest are all defaults then you don't hand em over when inserting from anywhere.

    If there's a top ten newsitems and you have a summary presented then you just have a cached top ten with 2 or 3 columns and invalidate as a new topper newsitem comes in. You don't insert a new top item, you insert a newsitem.   Whlst this might mean a cache of newsitems and a cache of top newsitems you do that because you need to for efficiency.

    Saturday, March 20, 2010 9:35 AM