Is it good practice to use data API for access cross platform

Question

All,

Question: Should I have a common data access API between various cross platform applications or keep the data access specific to the UI even though it would result in duplication?

Background: I’ve been developing various applications many with sub applications to interact with various pieces of our internal services. I basically have a desktop application that holds all these smaller applications / features and allows them to be used in a Launcher – almost MDI (but not) style and a web application that has various subset applications inside for our mobile devices. We’re getting to the point where many of our applications will have a desktop and mobile version of them and I’m curious about the best way to structure this. Currently I have a large common class library that stores all my data access in the form of an API which basically interacts with an internal DATA CONNECTIONS class inside the common class library alongside various common helper methods.

Additional: Primary data access is Entity Framework which requires a NuGet package for each project using the common class although I also have various manual data access methods as well. One of the concerns I have is that my naming scheme is messy I feel like by having the UI structured by “Application Name” and then having duplicate folders in my common classes also structured by the same name. Basically, looks like this:

Answer 1

What you appear to be missing here is a good story for what happens between your data access layer and your user interface.

Should you have a common data access API? Of course. But your UI will not necessarily be getting data directly from your data access layer. Why? Because the data that your UI needs might look different than what you get from your data access layer. Your data access layer is optimized for efficiency; your UI is optimized for display.

Let's say you want to display an invoice. Invoices have a rather specific structure. You have an invoice header containing addresses, invoice line items, and a summary block with totals. From the data layer's perspective, this information comes from several different tables. From the UI perspective, it's a single data structure.

So you can either have the UI pull all of the necessary information from the data access layer directly, or have some intermediate software layer retrieve the data, assemble the invoice for you and provide a single data structure to the UI directly.

The latter approach is more desirable for several reasons, mostly having to do with separation of concerns.