Replies

• allan Posts: 65,972Questions: 1Answers: 10,980 Site admin

  August 21

  Hi,

  The client-side doesn't really "care" what the backend is - you can readily consume any JSON data source with DataTables. It could come from the DataTables C# libraries, your own EF code, an ORM, Rails, a third party feed, a mock feed, whatever.

  The .NET libraries I provide are designed to cover the most common use cases for CRUD interaction with a database. They don't cover all use cases, and trying to do so with them would be folly!

  What data feed specifically are you thinking of that you'd like DataTables to work with?

  Allan
• unicorn64 Posts: 2Questions: 0Answers: 0

  August 22

  I certainly appreciate your work; I wouldn't want to be misunderstood.

  It’s just that, since work had already been done on the C# side for datatables.net, I thought a more general-purpose solution would have been better.

  I have a new project using ASP.NET Core MVC and Clean Architecture, and the application will rely heavily on tables. The data models for the table columns are already defined on the C# side, and the app needs to support multiple languages. Instead of writing DataTables logic on the JS side for every screen—specifically re-defining columns—I was researching how to create a DataTables API wrapper using a generic builder pattern on the C# side (e.g., generating the JS config via methods like ColumnFor(x => x.Name) based on data models). Just then, I came across DataTables.net version 3.0 and your work on the .NET side; seeing a structure tightly coupled to direct database queries made me wish there had been a more generalized implementation focused solely on generating the DataTables.net configuration.
• allan Posts: 65,972Questions: 1Answers: 10,980 Site admin

  August 23

  Hi,

  I think I understand a little better now - thank you. You'd like something more closely tided to ASP.NET MVC? I can totally understand that - when I initially wrote the .NET libraries for DataTables, I looked closely at doing this, particularly with EF, and ASP.NET MVC. The problem I ran into, which is exactly the same in the PHP world where I could have implementations for Laravel, Cake and others, and similar for other platforms, is that instead of just maintaining one generic code base, I'd need to implement, document, test and support for each framework. Furthermore, as new frameworks are added (Razor for example), they would need their own implementations and documentation.

  I fully accept that would be the ideal course, however, I'm just one person and simply don't have the time to maintain many different implementations for a single platform.

  The protocol DataTables uses to talk to the server is fully documented in the manual, and I'm happy to provide any additional information to anyway who would like to use a more framework native implementation. For example, if you have a REST API already implemented, DataTables can make use of that. Or if you have some other API style, you'll be able to manipulate the data sent from the client-side, and what is sent back, into what DataTables expects.

  I hope this helps explain my decisions a little bit.

  Allan
• Karen_75 Posts: 1Questions: 0Answers: 0

  August 24

  The .NET libraries mainly focus on database queries because that covers the most common CRUD use cases. DataTables itself is backend-agnostic and can work with JSON from APIs, mock data, ORMs, or other sources.