Early binding vs late binding in Crm d365

(0) Share

Report

Posted on by Rohit Negi

CRM Experts,

We have started working on D365 project which would be having very heavy customizations consisting of 150+ custom entities and most of the entities consist of 200+ fields on average. Major entities like account, contact,lead,campaign etc.. consist of 500+ fields as well.

Since soon we have to start building C# code(plugins/workflows), need to decide on which approach to take- early binding or late binding.

Please suggest what is best suitable approach considering the heavy application we are going to have.

Already went through different blogs on same topic but would be more interested in knowing experiences with this kind of scenario.

Thanks in advance!!

Regards,

Rohit

*This post is locked for comments

All responses (10)

Answers (0)

Temmy Wahyu Raharjo 2,914 on at

Like (0)

Report

RE: Early binding vs late binding in Crm d365

I prefer using early bound because we don't want to mess with the naming problem when get/set attribute. Also with using early bound you've got benefit because you know the data type of each attribute.

The cons, usually early bound plugin will got bigger size. You can check our framework in the link and you can ask whatever question about that framework.

PS: we also develop reduce and repack assembly, so when you build. The dll will drop all the attributes not needed!
Kenneth Leong 360 on at

Like (0)

Report

RE: Early binding vs late binding in Crm d365

oh that and hardcoded string. I have a strong opposition to hardcoded string (or anything hard coded) ever since my early development discipline. That's why there are such thing is enum, constant, etc
Kenneth Leong 360 on at

Like (0)

Report

RE: Early binding vs late binding in Crm d365

i apologize if i wasn't being clear. My position is why use late binding when it can hide bugs (runtime exceptions is evil). Early binding can get you all the places you have to change when models evolve over time. I'd rather get compilation error than troubleshooting runtime exceptions

Let me reiterate, there are scenarios where fetch/queryexpression shine (dynamic nature of language). Just like you can go back 15 years ago, and write sql statement and pump it through sqlcommand and get data. enjoy the string manipulation while you're at it. Or you can go with the time, and start using entity framework and use linq and nice OO classes.
Suggested answer

Guido Preite 54,077 Moderator on at

Like (2)

Report
RE: Early binding vs late binding in Crm d365

@Kenneth,

just two things:

1) you can do linq with late bound (see this MSDN example msdn.microsoft.com/.../gg334415.aspx)

2) if you need to dynamically add or not conditions to a query, it's easier to do with queryexpression than linq, something like this:

FilterExpression filterSearch = new FilterExpression(LogicalOperator.And);
if (searchWithFirstName == true) { filterSearch.AddCondition("firstname", ConditionOperator.Equals, firstName); } if (searchWithLastName == true) { filterSearch.AddCondition("lastname", ConditionOperator.Equals, lastName); } if (searchWithJobTitle == true) { filterSearch.AddCondition("jobtitle", ConditionOperator.Equals, jobTitle); } myQuery.Criteria = filterSearch;

so your whole answer has nothing to do between choosing early bound or late bound. If you are more comfortable using early bound, go for it, but in the end the only advantage of early bound is to know directly (IF the generated classes are up to date) which datatype is your field.
Kenneth Leong 360 on at

Like (1)

Report

RE: Early binding vs late binding in Crm d365

Sadly, it's posts like this one that people use to justify to use late binding all the way (ie. not generate, and use the Entity class and string attributes) *shudder*.. it gives me chill when is see codes like that. It's sad because people don't put justifications or objective analysis into their replies... probably because they are too busy doing crm projects. but there are a lot of new crm developers who first start, read this and just go with late binding... and didn't go deeper and look at the pros and cons of each.

I'm about 85% linq, 15% late binding. a couple of short and sweets: LINQ codes is fast to write, easy to write, easy to read, easy to troubleshoot, easy to debug, easy to maintain, etc etc. there are limitations - no no-lock, no left outer join and ever so slightly slower in runtime.. and sometimes you just want the flexibility of the entity class because sometimes you want your field to be a dynamic or depending on certain business logic.

I'm equally proficient in writing query expression and fetchxml, but why? when you can write 1 line of clean easy to read code, why write it in 10 lines of queryexpression.. why... i just don't get it.. linq is a framework developed by microsoft.. there's linq to crm, linq to sql, linq to xml, linq to xxxxxx. to unify the query syntax across all queries. so that if you have a strong entity framework background, you can jump right into developing for crm without much onramping.

i agree, the delta in performance can multiply if you're going to run a for loop over 10000. But that conjures up another nightmare when i see people puts 3 nested for loop to query data, instead of using join.

anyway... enough rambling. got work to do..
Mahendar Pal 45,095 on at

Like (0)

Report

RE: Early binding vs late binding in Crm d365

I also never used early bound but have seen people using early bound when they want to write a complex query using linq .
Aric Levin - MVP 30,188 Moderator on at

Like (0)

Report

RE: Early binding vs late binding in Crm d365

Also for Late Bound. Have used Early Bound in a few scenarios, but overall I have always used late bound. Jonas Rapp's Latebound Constants Generator is a good way of doing latebound with generation of constant classes from the metadata.

Good luck.
Suggested answer

RaviKashyap 55,410 Moderator on at

Like (1)

Report

RE: Early binding vs late binding in Crm d365

Hi,

+1 for Guido's response.

Personally I also like late bound with the entity constant in a separate file. With the Latebound Contstant Genererator tool in XRM Toolbox, it is more easy to have the entity constant updat to date.

Hope this helps.
Suggested answer

Guido Preite 54,077 Moderator on at

Like (0)

Report

RE: Early binding vs late binding in Crm d365

I have nothing against early bound but if you want my experience just go with late bound or use the new Latebound Constant Generator plugin from XrmToolBox, if you still want to use early bound then at least use the Early Bound Generator (also this inside XrmToolBox) to select just the things you need.
Suggested answer

gdas 50,091 Moderator on at

Like (3)

Report

RE: Early binding vs late binding in Crm d365

Hi Rohit,

I would suggest always use early bound in your project scenario for following reason.

I understand there is small disadvantages that every time you need to generate proxy class although you have following advantages-

- For early bound proxy class is common proxy class and increase reusabilityour in your code.

- Developer will not write any own property to make your code complex all are coming from proxy class. For late bound depends on developer .

-Auto intellisense support visual studio which will make faster your code to find attributes, entities. No intellisence support for late bound.

- Every time when writing code you don't need to check the entity name and attributes name.For late bound everytime you need to compare with CRM .

- There is should not be any error of attribute name anymore.In late bound you could found any error until you debug the code.

- Early bound performance is slower for short process, but long execution it's bit similar to late bound.

Hope this helps.