It seems you can refactor the fetching process to hide complexity, please let me know the drawbacks of what I suggest:
ATM to fetch a listbase using custom criteria the developer must create a custom myCriteria object, create a '.Get(myCriteria criteria)' for the object, and override DataPortal_Fetch. Why the complexity?
As far as I can see, all criteria boil down to a stored procedure name and a parameter list, so you can make one criteria object called for example FilterCriteria (with properties FetchSP and Parameters). Instead of polymorphically dispatching on it in Get(...), make a generic signature: 'public static T Get(FilterCriteria criteria)'. This invokes 'return DataPortal.Fetch<T>(criteria);'. In the callback 'private void DataPortal_Fetch(FilterCriteria criteria)', the stored procedure is set this way:
cm.CommandText = criteria.FetchSP;
if (criteria.Parameters != null)cm.Parameters.AddRange(criteria.Parameters);
Since the fetch can generically operate on any .Get off any filter criteria, it can be moved up the inheritance chain and completely hidden from the developer, saving a ton of duplication. Is there something wrong with this approach?
We do this in exactly the same way, which works very fine IMO.
A refinement can be that you do not want to expose the FilterCriteria to the UI. When this is the case you can create different static functions that use the filterCriteria. For instance
pubic static Order GetOrderByName(string name)
{ Get(new FilterCriteria("GetOrderByName", new IDbDataParameter("name",name) ; }
public static Order GetOrderById(GUID id)
{ Get(new FilterCriteria("GetOrderById", new IDbDataParameter("id",id) ; }
Of course this code will not execute, but I think the idea is clear.
The data portal is designed to impose as few restrictions on your code as possible. I use it one way in the books, but it is really quite flexible.
If you get right down to it, in fact, the data portal is largely independant of the rest of CSLA. In fact, you can get/update any object through the data portal, as long as that object implements DataPortal_Fetch() and DataPortal_Update() methods. And, of course, you are able to pass some criteria object through to the DP_Fetch() method.
So coming up with ways to simplify code that fits into your overall environment and architecture is a wonderful thing, and is one of the reasons why I've kept the data portal as inobtrusive as possible.
Copyright (c) Marimer LLC