Repository Organization

Yes, if you use UoW you'll have one repository per type and one factory per type and zero or one domain service(s) per UoW. The UoW then brings together all the repositories and factories for all the types that are involved in a particular type of UoW plus the necessary domain services for the business logic/processes. In TempHire for example there's only one UoW and it brings all the repositories and factories together. TempHire doesn't have any domain services, because there aren't any business processes at the moment.

 

Documenting the whole UoW stuff is an outstanding item on my list. I'm still toying with the current implementation. You may have noticed that additional functionality has been added.

 

I would have to dig up a good reference, which will take longer than trying to explain it. Domain services is a wide term and essentially captures everything. Repositories and Factories are technically domain services as well. In this case though the domain services are anything that isn't a repository or factory. These are most often cross entity business processes and business logic.

 

For example, let's say we are building an application that transfers money from one account to another account. So, we would have a unit of work type representing this workflow. The unit of work would have an account repository, so we can retrieve accounts. But where should the transfer logic go? This is a case for a transfer service on the UoW.

 

We would create a stateless transfer service with a method called Transfer that takes the account number for the source account, the account number for the destination account and the amount you want to transfer. The service would then use the account repository, which it was given by the UoW, to retrieve each account, check any applicable business rules, deduct the amount from the source account and add it to the destination account. When all is good, you ask the UoW to commit the changes. You typically expose all these domain services as properties on the UoW and it is the UoW's responsiblity to configure them, so they work within the confines of the current UoW.

It is generally accepted to put logic on the Entity if the logic is self-contained, meaning it doesn't have to step outside of the aggregate. All the data the logic needs is either in the root entity or in a related entity that can be accessed via navigation. That's not the case here. This logic involves two accounts that are not directly related. Even if your logic is constrained to the aggregate you have an issue in Silverlight, because navigation is asynchronous. What if the related entity is not in the cache? Now your logic is making assumptions on the state of the cache. You'll find yourself in a ditch pretty quickly if you rely on such assumptions. The first sign of trouble is when entities are being passed around instead of IDs. Every time you are being passed an entity you have to rely on all data to be there. That's dangerous business. Even in the synchronous world this is an issue. It leads to accidental roundtrips and the infamous n+1 problem. I see it happen all the time when a customer calls and complains about performance. Developers made assumptions about what is in the cache. The assumptions may have been correct 6 months ago when the logic was first implemented, but things have changed, new requirements have been added another developer has refactored something and all the sudden your performance goes down the drain, because you are unaware of the hidden roundtrips. Often as a quick fix, developers start adding Include after Include and soon bring down massive graphs that make things even worse. Trust me, I'm currently sorting through exactly these issues with a customer and it's not the first time.

 

Implementing this as a stateless service puts everything in one place. The service conditions the cache for the logic and then performs the logic. If you need to refactor you have one place to refactor. No assumptions on what the current state of the cache is.

 

Yes, most of the logic is on the client. This is the paradigm of RIA. Rich clients leveraging the power of the client device. Done right, this yields much better performing and more tolerant applications, than the traditional apps that rely on services on the server to perform logic. In a true RIA app you can still do stuff even if you have intermittent connection to the server. It's the offline kinds of capabilities that make the app much more tolerant to network and server outages. The downside is that if you change platforms completely as in moving from C# to Javascript then you'll have to reimplement your logic. The question is what is more important to you and your customers? Generally the customer cares about the experience and performance of the application today and not how easy it may be for you to port it to another platform if that time comes.

 

Yep, you got the idea. Yes, you pass the repositories into the constructor. You may even need to pass factories if your logic involves creating new root entities. Related entities should be created through the root entity as demonstrated in TempHire. Remember, the repositories and factories are services themselves, so you are not adding state to your domain service. You are giving it other services it needs to perform it's function. The EntityManager which holds the state is hidden behind the repository.

 

To your last point, server and client are really different. The client should be all asynchronous even in WPF. Notice how my UoW implementation is all asynchronous. It's the future and synchronous apps simply suck. WinRT/Metro just like Silverlight won't allow synchronous server calls in order to keep the UI thread free to respond to touch input from the user. Blocking the UI thread while retrieving data is a bad user experience and leads to poor performance.

 

On the server the world is synchronous, because the server already is multi-threaded. Each request runs on its own thread. So, you have fundamentally a different usuage paradigm on the client vs the server. You could break out the core logic, which acts on the entities once they are loaded. That core can be shared between server and client. You simply front it with asynchronous prepartion logic on the client and synchronous preparation logic on the server.

 

On the other hand the new Javascript clients that everybody is talking about now are still RIA. These are not web sites with a little AJAX sprinkeled in. What you are doing in XAML and C# today, you'll be doing exactly the same in HTML5 and Javascript, just a lot less productive for a while, because there is nothing like Cocktail today or like DevForce. Microsoft just pulled the plug on upshot.js and are going to rebuild it, so all the MVC 4 stuff coming out won't have a way to query/save data from a client.

The TempHire sample is excellent but my biggest issue with it is it only has one main component, StaffingResource. There is one very large form (Resource Management) made up of many smaller VMs and Views. The whole application has one UoW for the entire application. My question is how do you manage the UoW paradigm when you multiple modules and forms?

For example we have an application with two modules: Employees and Customers.

The Employee module has many forms: Dashboard/Overview, Details, WorkHistory, Education, Messages, etc.

The Customer module would be laid out in a similar fashion. 

In the case of TempHire you have these forms displayed as tabs in the main StaffingResource form. In our app these tabs are broken out into separate forms. Would each form have its own UoW or a single UoW for the entire module. I could see case for both ways. A single UoW would work since in a way all these forms are tied to a single Employee entity but like my current repository could get super large and I am newing up objects my form wouldn't use. If I go with each form having its own UoW then every form has it own EntityManager and I feel that gets too granular.

Any opinions? Thanks...

 

Now, that you have the types, how many instances should you create? Which VMs should share one instance and which VMs should use their own instance? The answer comes down to your application requirements. A UoW instance represents a single transactional changeset in your application. You save it as a whole or roll it back as whole. Think of it as a task. In TempHire, the UoW instance lives at the StaffingResourceDetailViewModel level. Every VM below that shares the same instance. The task in TempHire is defined as creating/editing/deleting an entire StaffingResource with all it's related entities. The main version of TempHire only allows for one StaffingResourceDetailViewModel at a time, so effectively you only have one UoW instance in flight. It's actually not quite true, because the search grid at the top uses it's own, so in fact you always have two instances in flight.

 

The MDI version of TempHire (http://sdrv.ms/KNZkJz) on the other hand allows you to open multiple StaffingResources at a time and edit/save them independently. Each tab with it's subtabs in this case gets it's own UoW instance. Now you can truely have multiple changesets in flight and save or roll back each one independently of the others.

 

If you start breaking out VMs into seperate forms you may do that because your application requirements dictate that different parts of a larger aggregate must be editable independently. If that's the case, then you would have a new UoW instance at those points. Wherever you need an independent saveable changeset, that's where you use a new UoW instance.

 

Lastly, if you are worried about the UoWs instantiating all the repositories, factories and services, even though they might not all be used at any given time, you can always implement your UoW to lazy instantiate them instead of instantiating everything in the constructor.