Best practices for custom web parts

Sasanka Athauda asked on April 19, 2017 08:35

Hi Kentico .NET Experts,

We are in the process of implementing an enterprise application that is going to be hosted in Kentico. We will have a database structure consisting of multiple database tables with one to many relationships. The in house Kentico developer suggested we use custom tables option to generate the database tables.

I would like to know what would be the best practice for setting up a back-end database tables?

  • Use custom tables and setup the tables via Kentico admin
  • Use module classes feature to create the database structure
  • Create the database tables via scripts (specify foreign key constraints) and use .NET entity framework to access the data

From my research, if we use custom tables option, we won't be able to use Linq queries while .NET Entity framework will work perfectly with Linq. Also we are required to use TDD so we need to implement clear separation of data layer and business logic.

I would like to know what would be the best approach for such a situation.

Your advice is much appreciated :).

Cheers, Sasanka.

Correct Answer

Chetan Sharma answered on April 20, 2017 10:09

Although Roman has already said that. We recently are heavily banking on custom modules to implement a lot of relational data and have immensely benefited from a lot of features that it does provide.

  • A Quick way to build relational data. Of course not as flexible as real DB however once you get past the required learning curve, spinning up custom modules will be a cake walk.
  • You will also be able to have versioning control on your data if you do care about that will not be possible with Custom tables. CT are too bland.
  • Kentico will generate and of course you will have to press the regenerate button to generate code for Info and Provider classes. This will give you a robust boilerplate code that could be useful at other places.
  • Most Kentico will provide REST API on top of your Custom Modules data that makes providing this data to other teams just too easy. We do this a lot. It's hassle free.

Cons

  1. Learning curve is high. You will have to bang your heads for few days before things will fall into place. Martin Hejtmanek, Kentico's CTO has an amazing lecture series on this which I found better than the documentation. I am providing you with link to the first article of the series. You can follow links to read all other artciles of this series.

  2. We have faced a lot of problems moving data from one server to another while using Custom Modules. We faced a lot of problems where keys end up not matching and also using staging service for CM data. Just a heads up.

  3. Regardless of everything we are banking a lot on CM this year to architect things we did in nascent stages between 2013-2015. We are really liking it.

P.S - We have done 10+ CM implementations as of now across different projects.

3 votesVote for this answer Unmark Correct answer

Recent Answers


Roman Hutnyk answered on April 19, 2017 11:03

Please see comparison between custom table and custom module here.

I'd recommend using custom table in case this is stand alone table and has no relations with other objects. In case you have more complex data structure than a single table - use custom module.

Kentico provides you with API to manipulate data: use ObjectQuery instead of EF.

1 votesVote for this answer Mark as a Correct answer

Sasanka Athauda answered on April 19, 2017 11:14

Thanks Roman for your quick response.

From my research, when you create custom modules, the object classes are generated for you within the Kentico solution. Can these data classes be moved to a different project? We are required to use TDD so we need to have a clear separation of the data layer so we can write tests on the data access.

Also any particular reason for choosing custom modules/Object Query over manual tables/EF?

Cheers, Sasanka.

0 votesVote for this answer Mark as a Correct answer

Roman Hutnyk answered on April 19, 2017 11:21

Yes, you could store generated classes into a separate project.

Kentico generates classes for a custom table as well.

ObjectQuery is Kentico specific feature that has some extra functionality/methods like .CheckPermissions() or .Published() that would be a real pain to implement them with EF.

1 votesVote for this answer Mark as a Correct answer

Sasanka Athauda answered on April 19, 2017 11:27

Thanks heaps Roman. I really appreciate the info. I'll do more research on Custom Modules and raise question if I have any.

0 votesVote for this answer Mark as a Correct answer

Chetan Sharma answered on April 20, 2017 10:08 (last edited on April 20, 2017 10:08)

A

0 votesVote for this answer Mark as a Correct answer

Sasanka Athauda answered on April 26, 2017 01:52

Hi Chetan,

Thank you very much for the detailed information regarding custom modules.

I was hoping whether you would be able to provide some insight into the questions below:

  • Are there any known limitations with custom modules like not supporting certain data types?
  • Does Kentico handles performance improvements automatically like creating table indexes?
  • How flexible is ObjectQuery on custom modules as oppose to Linq?
  • When using CM/ObjectQuery on a scalable solution, how is it's performance compared to Entity Frameowrk/Linq?

Thanks again for the information and look forward to hearing soon :).

Cheers, Sasanka.

0 votesVote for this answer Mark as a Correct answer

   Please, sign in to be able to submit a new answer.