locked
Question on Custom Entities RRS feed

  • Question

  • I have a scenario wherein the UI talks to Service layer --> Business Layer --> Data Layer and fetches data and passes along the layer via custom entities. Typically when we retrieve records it would as a set of entities inside an entity collection or should I say an array of entities.
    Now when I update a particular entity in the entity collection I either have the option of sending the entire entity collection or just extract out the updated entity and send the same across the layers to be updated in the database. Looking apparently, it would suggest sending only the updated entity instead of the entire entity collection bcos its always best to pass small size data across the layers.


    Is this analogy correct or is there some scenario which i havent considered which would necessiate the passing of entire entity collection instead of the updated entity.

    In case if I do consider only sending the updated entity, is it better to do the extraction at UI layer  before sending it across to other layers for performance reasons?

    Would like to know your thoughts on the same

    Thanks
    Sai

    Tuesday, December 26, 2006 4:38 PM

All replies

  • The only time I could see a need for passing more than one entitiy to the database would be if the collection was stored as a single object in the database so that you needed the whole collection to do the update.  Unless the collection is exceddingly small, this would make no sense so it's safe to assume you would pass a single object.  This implies that you can uniquely identify each object through an object id or database key so you know unambiguously which entity is updated.  This might require you to include both the old and new values if the key is changed but you should try to pick a key that doesn't change.

    If you maintain order in the collection you might decide it's easier to re-retreive the whole collection from the database if the attribute your collection is ordered by is changed rather than writing the code to move the entity to a new location in the collection.  A good example of where this is the best way to do it is a collection that is maintained in alphabetical order based on the database locale.  You may not be able to do this in your application because you don't have access to the character sets used in the database.

     

    Tuesday, December 26, 2006 5:31 PM
  • Well a typical scenario what I was thinking of is when I retrieve a set of records to be displayed on to a datagrid. It would return me an entity collection and the same I would bind it to the grid. Now say it has got 5 records and out of which I have updated 3 records. This in turn would mean updation of 3 entity objects in the collection. So now I have the choice of updating the same collection and marking the flag as dirty and sending it for database update or I extract the updated once from the collection, put it into a new collection and then send it to the database for batch update. Typically scenario for such kind of behaviour is a Master Detail kind of form.

    So in that case it would better to send a collection instead of a single entity object 3 times across the layers
    Tuesday, December 26, 2006 7:10 PM
  • One advantage of using a new collection is that you can design it / extend it for situations other than you're UI without affecting the existing collection design.  For example, you can make the "update" collection easy to serialize for XML or add logic so that BizTalk orchestrations (for example) can more easily access your system.
    Tuesday, December 26, 2006 7:33 PM
  • That depends on how your collection is implemented.   If you are using a dataset for example, the dataset logic will handle sending only the updated records to the database.  If you are using some other kind of collection bound to your grid then the answer is going to depend on the tradeoff between network efficiency and programming effort.  If you have to write a lot of code to implement the single entity update and the collection isn't all that large it make make sense to just send the whole collection but if the collection is huge or if the collection logic can handle the entity at a time update for you then that's definitely the more efficient option.
    Tuesday, December 26, 2006 10:47 PM
  • It really depends on your design and deployment viewpoint. Would all these assemblies be loaded in a single AppDomain? If so, I would suggest passing the entire collection with the updated entities marked as "Updated" to the business layer which passes it on subsequently to your persistence layer. Please note that there will no performance issues as only the reference of your collection is being passed around and not a copy of it. Also, this will perform much better than creating a new Updateable collection as it has suggested in the prior posts. But, if you are designing true services for your Business and Persistence then you really have to design it from a flexible viewpoint. In that case, you could overload your Business and persistence methods to take either an IEntityCollection or IEntity. The UI Process Elements govern which method will be invoked as it would have the meaningful execution context to determine whether to pass the entire IEntityCollection or just a single IEntity.

    Hope it helps,

    Tarun

    Wednesday, December 27, 2006 7:19 AM