Coding – Page 6 – BinzBlog

Passing Code Blocks, That Doesn’t Sound Right?

I have been working on an application that makes heavy use of Windows Communication Foundation (WCF) proxies. Do to an issue with how the Dispose method is implemented on the WCF client base class you aren’t supposed to use them in a ‘Using’ block. To accommodate this what we encountered was the same try, catch ,catch,catch block around any instance of a WCF client proxy in our code.

The below example was common in our code:

What we realized was that we could use generics and the fact that all WCF clients inherit from the same base classes and implement the same base interfaces to pull the common init and clean up code out into one place. Luckily for us the ‘Abort’ and ‘Close’ methods are both implemented by the ‘ICommunicationObject’ interface and all WCF clients implement it. Just like the ‘Using’ statement wraps a try/finally block around a code block we want to wrap our try/catch/catch around a code block. Continue reading “Passing Code Blocks, That Doesn’t Sound Right?”

Refactoring To Smaller SRP Service Objects

Currently I’m going through a very procedurally driven code base and attempting to break code out into smaller service objects called by the main class. The code I’m working with deals with creating, validating, fetching and saving orders for our products. I’m doing this refactoring for a couple of reasons.

First of all I want to have code collected into service objects that have similar functionality. Ideally I’d like each service class to comply with SRP, and have only one reason to change. There are many methods in the original code base that deal with creating orders, so I’ve factored those out into an “OrderBuilder” class. This class is concerned with putting an order together. I’ve broken out code that has to do with persisting an order into an OrderDataManagement class. Not only does this better adhere to SRP, but by doing this it seems easier for me to find the code I’m looking for. Business rules for building an order are in the “OrderBuilder” class instead of buried in a much larger “OrderManagement” class.

The second reason I’m doing this is to make things easier to test. In the original code I could mock a data connection, but if I wanted to test anything else I had to account for everything going on around the behavior I was testing. By breaking out the code into smaller more cohesive and less couples service objects I can mock the behavior I’m not interested in, and focus soley on what I’m trying to test. This is allowing me to add tests for new or changed functionality much faster, and tests aren’t nearly as brittle as before.

So far so good, hopefully I’ve made things better, we’ll see how I feel in a few days.

Using LINQ Expressions For Dynamic Predicates

I ‘ve recently been building a set of reports that all output data in a common format, and also group their data in a common format. Each report needs to be able to have a date predicate based on day, week or month. Using LINQ to LLBL Gen Pro (the ORM tool I’m currently using) I set up a base report class that has abstract methods defining the date predicates and query bodies, but share the grouping and output mechanisms. What allows this is being able to return a LINQ Expression in the methods that define the date predicates.

The abstract date predicates end up looking like the below:

protected abstract Expression<Func<T, bool>> GetDayDatePredicate(int reportBuckets);

Once implemented the date predicate ends up being something like:

protected overrides Expression<Func<dataEntity>,bool>> GetDayDatePredicate(int reportBuckets)

{

return d => d.CreatedDate.Date > DateTime.Now.AddDays(-1 * reportBuckets).Date;

}

Having the predicates in method form serves two purposes: first the method name clearly states what the predicate is doing, (fairly straightforward above but bucketing by weeks is not nearly as clear), and second it allows the base class to create the query by doing something like the below:

public void RunQuery(int numberOfBuckets, IQueryable<T> q)
{

Expression<Func<T, bool>> datePred = GetDayDatePredicate(numberOfBuckets);
q = q.where(datePred);
RunQuery(q);

}

This allows a base class to manage running several reports if they all have similar structure. When adding a report I just add a new implementation of the base class and fill in the abstract bits and then I know I have a report that our UI can use, since it relies on the common output the base class enforces on its children. Don’t know if it’s all that good a solution, we’ll see.

LINQ To LLBL Group By – Two Queries To Get Count

For a persistence layer I’ve been using an ORM tool called LLBL GenPro. I’ve chosen this tool up until now because LINQ to SQL or DLINQ or LINQ to Entities, as it’s called now, seemed like it was very prone to change. I decided to wait until it settled and may begin to use it soon.

In the meanwhile LLBLGen Pro put out a LINQ implementation of their own, so I’ve been happily using LINQ with my ORM tool. I’ve been having some interesting Group By issues, however.

The main problem I’ve had is when trying to use a function like count, or sum. When I write the below I get a sql error :

var customerOrderByDate = from c in Customer
join 0 in Order on c.CustomerID equals o.CustomerID into fullRow
from x in fullRow.DefaultIfEmpty() //forces left join
group x by new { x.CustomerID, x.CustomerName} into ordersGroup
select new { ordersGroup.Key.CustomerID, ordersGroup.Key.CustomerName, ordersGroup.Count(x.OrderDate != null) };

Oddly enough I can make the above create valid sql by separating the LINQ query that creates the data to group and the grouping itself into two separate LINQ queries. Even though the below is two LINQ queries it produces one sql query which does what I want.

var customerOrderByDateData = from c in Customer
join 0 in Order on c.CustomerID equals o.CustomerID into fullRow
from x in fullRow.DefaultIfEmpty() //forces left join

var customerOrderByDateGroup = from data in customerOrderByDateData
group data by new {data.CustomerID, data.OrderDate.Date } in ordersGroup
select new { ordersGroup.Key.CustomerID, ordersGroup.Key.CustomerName, ordersGroup.Count(og.OrderDate != null) };

I would expect the first query to function the same as the the two split out but they don’t. Probably an issue with the LINQ to LLBL implementation. I’m sure that was very difficult to do and I’m happy it works as well as it does.

One other problem I’ve noticed is that the boolean lambda expression in the Count method is required, but it doesn’t seem to do anything. The SQL always produces Count(*) regardless of what is in the lambda expression and Count() doesn’t compile.