locked
CRM 2011 Architecture Question RRS feed

  • Question

  • I wanted to get some ideas of how others are structuring/architecting their CRM applications.  Here's what I am doing...

    1. Adding JavaScript entity/form customizations... using REST.Jquery for db access.
    2. Adding a couple of plugins to handle CRUD operations against a few entities.
    3. Adding HTML web resources to replace the usage of dialogs, as the dialogs just cannot handle what I need.
    4. I will be adding a integration/real-time sync to a legacy database/application and I am not sure exactly what the best approach will be for that.

    So I started with customization the forms using JavaScript and using REST.JQuery in the JavaScript.  I don't really like doing client-side database operations.  So I am considering moving this to server-side and coding it in C#.  I just don't know exactly how to do that in CRM.

    I have built a couple of plugins to handle some things my dialogs could not handle (mapping boolean fields from one entity to another) and that approach works very well.  So I think my preference is to work in C# over JavaScript and the more I can move to C#, plugin, etc. the better off I will be. 

    I have built some HTML web resources, but I haven't gotten very far because having to do all of my data access in JavaScript has been very painful.  So maybe moving the data-access into service-side C# would make more sense.

    So, I have a couple of simple questions.

    1. What are some best-practices/designs for doing HTML web resources in regards to database access?  Are people building web services, or are there extensions like plugins you can setup and call from web resources?  Is the typical approach to do ALL of the database work in client-side JavaScript?
    2. I need to start building integration between a legacy application and database and CRM.  I'm not sure about building dozens of plugins and each having it's own data-access code.  I was thinking a class-library would make more sense, then just have all of the plugins working with the class-library to access the db.  If this was a pure ASPX app, I would have built a web-service, a service class, a data layer, etc. A similar model seems reasonable here.  But CRM is a bit unqiue and I am not so certain.
    3. With the plugins I am writing, it seems logical that I could build a data-access class library that the plugins could interact with.  Then, if I end up with a web service that my HTML web resources call, that same class library could be used as well.  However, I am not sure if that makes sense since CRM already has it's own web-service.  So maybe the best approach is to consider CRM and the various services like the REST and OData services to be my data-access layer. 

    Any thoughts or ideas would be much appreicated. How are others architecting this sort of thing?  I am really curious at how best to architect the HTML web resources, client-side JavaScript, and server side code.  How are people approaching this sort of thing?  I'm thinking web services, but that's not going to work in an off-line mode, which might be ok for me.  But I don't have enough CRM experiance to know if this is a good approach or not so I would like to get some idea of what others are doing here.

    Best regards,

    Jon Rothlander


    Jon Gregory Rothlander





    Friday, February 28, 2014 2:47 PM

All replies

  • You do not need to develop all of your CRM UI extensions using HTML webresources. When you are dealing with an on-premise deployment, you can perfectly develop your web pages on ASP.NET.

    When you are confined to webresources though, I would advise you to make use of some popular Javascript libraries that can ease the pain of developing web applications. KnockoutJS i.e. simplifies the binding of JSON data objects to the UI dramatically. And of course jQuery is a no-brainer.


    If this post is an answer or helpful, please do not forget to vote!

    Tuesday, March 4, 2014 8:34 PM