Latest Service Layer In - Unit Tests Passed

Coordinator
Oct 27, 2011 at 1:16 AM

The latest pieces are in...

As it stands now, the ServiceBase will handle basic CRUD operations pretty seamlessly.

Current Association Types Tested Against: Complex Types, 1:many, many:many.  1:1 is not a problem...works the same way.

However, there are two snags:

1.) Calling update from the service base will only update scalar properties and complex properties (fyi - complex types live with the lifetime of its entity and are in the same table in the db - just another class in code - see fine-grained domain models).  To add or review modified items, you will need to use a more specific method that will handle those graph operations.  For example, if you look at FooService, which inherits from ServiceBase, you will see it has two methods: a.) UpdateFooGraph and b.) DeleteFooGraph.  These methods are a little involved but they are very simple to follow. 

2.) The convention right now on inserts and deletes of child items is best explained with an example -> Given two Foo entities, new and original, where new is the Foo entity will all new/removed siblings and updates and original being what's currently persisted in the database, the algorithm simply looks at new for items that are not in original.  In those cases, they are added.  If, however, the same item is found, that child item is updated.  In the case of delete, any item in original that is NOT in new gets smoked...

The snag here is we curently do not have a way to stop processing the entire graph.  For example, if Foo has 15 objects on its 2nd level, and you only want to update Foo itself and only of the items on the second level, we dont' have it.  Shawn and I discussed passing a list of Types that Foo contains that we want to process. 

We have two choices in this regard:

1. We can set these types at the time we create the request

2. We can set these types in the request itself.

3. We can use a convention based approach, where if a collection item is null in the new item, we do NOT mess with the original's corresponding collection items. 

The downsides to each are as follows:

1. In every controller action method where you create the request, you have to explicitly pass in the types you want updated.  This can probably be mitigated with a mapping file so we don't have to keep typing the types each time and to stay more DRY. 

2. You will have to create a different request for different update combinations; ie, you have one view that updates A, B and C and you also have a view that updates A, C, D.  In this case, you create two disparate requests.  This can use some a base class and you just set the types on each subclass, so it's not that bad -> but it can turn into a lot of files to maintain. 

3. Pain in the butt to ensure the right things are nulled out.  In many regards, this is much worse than option 2.

Please give me your thoughts on this as soon as possible?

Also, if you have other ideas, post those as well. 

I'm ready to get to the project itself and out of the infrastructure stage...