How would you model project plans and particularly rules for valid plans when the project plans can come from the following sources?
1) project server
2) the automation client
3) local database
I want to 'normalize' the behavior of business rules related to validation of the project plan. Would you create a project model to load the project from the project server using the PDS (project data services) or a remote data portal? The automation client has a different performance curve than the database. A local MS Access database adds a different set of characteristics. However, the rules that validate a project plan are the same regardless of where the data comes from. Would you have a 'ProjectPlan' Csla object with 3 different data access models? This makes the automation client data access VERY complex and creates poor performance.
How about a ProjectPlanValidator? I still need a hierarchy of iterators that can traverse a rather involved object model. Any thoughts on the business objects invovled?
Yes, I would have 1 object with all of the ProjectPlan business rules. The fact that you have up to 3 different data sources should not be that complex. The DataPortal_XYZ methods for data access are very isolated and in fact should make it very easy to implement 3 data sources for the same object.
You should look into creating an interface to get around you issue. Then have your ProjectPlan business object implement this interface. You could also have a web.config setting (or even a criteria parameter) that tells what is the datasource being used so that you make the appropriate call to you data souce via the interface.
The interface could look like this:
using System;
using System.Collections.Generic;
using System.Text;
namespace MyNamespace
{
/// <summary>
/// Interface implemented by server-side data portal
/// components.
/// </summary>
public interface IProjectPlan
{
object rows = Fetch(object someParameter);
int rowsInserted = Insert(object someParameter);
int rowsUpdated = Update(object someParameter);
int rowsDeleted = Delete(object someParameter);
}
}
Hope this helps
Yes, I took that approach to begin with. However, there are 2 dozen data entities related to a ms project plan. The interfaces that have to be implemented with this approach are quite complex after awhile. The trick is the design of interfaces for all the entities involved. I frequently use an interface in my data access layer objects to isolate data access from the business object. Normally, I use the IDataReader interface to pass data back to the business object. That way I can create mock objects for testing. However, the number and complexity of project plans require a more sophisticated interface. Especially when considering the automation data source, which is significantly different than the database structures.
The interface structure will have to be some kind of facade or even a flyweight pattern I suppose.
Another challenge that I tried and gave up on was the testing piece. I could NOT figure out how to test the automation object hierarchy implementation using NUnit tests. The problem was Ms Project's automation heirarchy seems to only operate inside of the client. So I did not figure out how to start the client from a test that could then access the automation object as a data source in order to test the implementation of the data access interface. I could test the consumption of the interface in the business objects easy enough, using NUnit and mock objects.
Another issue related to using the automation objects in Ms Project, is the method of accessing the automation object. That object exists BEFORE the business object does and must be encapsulated with the implementation of the data access layer's interface and then passed to the business object. This is a problem because this requires a 'RunLocal' attribute on the dataportal methods which have to be able to communicate with a remote dataportal to use the project server.
Perhaps the automation object, project server and ms access data sources require 3 different business objects and the business rules must be somehow encapsulated as a visitor. This way the various business object hierarchies could validate against the same set of business rules that are implemented in the visitor. What do you think?
This is where to buck stops for me. Evidently the issue your facing is way more complex that I originally though and I'm afraid I don't have any other clues for you, sorry!
I will trust that someone will take over with some sort of a solution for you.
I attended a preview of the Ms Project 2007 client/server last night. Now I have to look ahead to changes in all 3 data sources.
the database of the server is going to change, the local database structure will change AND the automation object hierarchy will change dramatically. So I have to consider how to implement rules across very complex object hierarchies that will change in the near future.
Perhaps normalizing behavior is NOT a good thing to do in this case.
Copyright (c) Marimer LLC