Anti Corruption Layers: Striving for FizzBuzz level
I think that I mentioned that I don't really like Microsoft CRM development options. Considering the typical quality of the code that I see online when I search for samples, I certainly see the CRM as corrupting influence.
That is why I pulled the big guns and built a whole new layer on top of it. I assume that you are already aware of my... reservations for leaky abstractions, and considering my relative lack of expertise on the CRM itself, I don't think that it would have been wise to diverge too far from the model that the CRM has, only to break the way we are handling it.
As a result of that, we have this piece of code, which is how I handles tasks that are usually handled by callouts. The major advantage is with the ability to develop on the local machine without being tied to the server, and a lot of smarts with regards to banishing XML parsing from the core business logic. The end result, as far as I am concerned, is that I should be able to write business logic using Fizz Buzz level of code, if that. It is a bit mind numbing, but that is what the client wants, not to struggle mightily with the underlying platform.
[Handles(CrmOperations.PreCreate)] public class OnCreateFriend_SetFullName : NorthwindCommand<new_friend> { public override void Execute() { if(string.IsNullOrEmpty(PreState.new_name)==false) return; PreState.new_name = PreState.new_firstname + " " + PreState.new_lastname; } }
And to foretell questions, the basis for that is not Open Source, although we may make a product out of it at some point. (Drop me a line if you are interested).
Comments
Anti-corruption layers are well worth the effort, IMHO. We've just done the same thing with the web service interface to SQL Server Reporting Services. I think that the trouble with their API results mostly from limitations of SOAP, but covering it with a facade that can take advantage of things like generics is a huge help.
Sounds interesting. Do you on the background still make use of CRM Callouts? How do you set any validation messages?
Yes, the lowest level is still a callout, but that is literally something that I no longer thinks of.
Something like this:
public void Execute()
{
DateTime start = PreState.new_startdate,
if( start > end )
{
}
}
Hmm, that's what I really like.
Now the above classes can be built, I'm thinking about the next step. Making these business rules available through webservices, so we can call them from within Javascript. Because after any business rule like the above, the user needs to reenter the complete form, we don't want that, do we?
So instead of creating Javascript for the business rules also, I'd like to have a small simple javascript function that internally calls a webservice that can make use of the business rule designed for callouts. This way no duplication of business rules can happen.
Part of the things that we did was to enable jQuery integration, so we can have (local on my IIS machine) JS files that does stuff like:
$(document).ready(function()
{
$('#new_startdate').change(onDateChange);
$('#new_enddate').change(onDateChange);
});
Since jQuery supports ajax with $.getScript('path/to/server') this is ridiculously easy to handle
I am thinking of adding MonoRail integration as well, which would make this really a piece of cake.
Hmm interesting, specially for the larger CRM projects, because the customizations are sometimes a little pain in the ****. Never thought about this to be easier than my thinking had in mind. Unfortunately jQuery isn't part of my knowledge, yet.
Comment preview