1 class model or 3 class models? 1 for each - UI, Hardware API Library, and Database

Question

I've always used one class model in all 3 area's of my projects. User Interface, Hardware API (for data collection), Database (entity database context). Every new project only seems to grow in size, which means it gets hard to change the class model because everything uses it.

It was suggested to me by seasoned programmer to split up my class model and use a different one for each part of my project. Then convert the data between models with passing data back and forth between the different parts. Which means if one of the models change that you only have to change the code in that section and change the "converters".

Is this a general practice? It's definitely more work initially but I am wondering if it will save me time in the future.

EDIT: I changed data model to class model as suggested in the comments. Though what I am specifically talking about is data modeled in classes in my application.

• Doc Brown: The term "data model" is typically used in the same sense as "database schema". But you talk of "a data model for UI" - so I guess you mean something different like a class model or module structure of your code? Please clarify.
• TheColonel26: Yes that is what I mean, it is classes that are modeling data. I changed it in my question

Answer 1

So it sounds like your projects typically have three areas: data collection, storage, and presentation. There are tradeoffs between the single model and multiple models approaches.

With a single model, is it very easy to ensure consistency across all the areas of your project. With multiple models, unless you build in mechanisms for automatic updates (and cope with the subtle bugs that that can lead to), it is possible for them to become inconsistent with respect to each other.

With a single model, as the demands of access to the data increase as your project grows, its interface can get bigger and its internals can get more complex and unwieldy. With multiple models, you must define and maintain interfaces for each model and write a lot of code to pack and unpack data for transfer in and out of them.

It sounds like you already have good modularity in your project, with separate UI, collection, and storage modules. A single data model becomes a fourth module. I'm not convinced that moving to six modules (a separate model for each module) will help things.

What I recommend is that you keep the single model, but give it three interfaces, one for each module that interacts with it: UI, collection, and storage. The UI module would see only the UI interface for the data model, and would not know or care how the data is collected or stored. Likewise for the collection and storage modules. In general, programming in terms of interfaces is very good practice, as it can limit complexity and keeps coupling to a manageable level.

• TheColonel26: That makes sense I'm just not sure how to implement that with Entity Framework. Since with entity framework the data model and the storage are so integrated together. I've used interfaces to represent difference daq hardware before (Multiple classes 1 interface) but I have never implemented multiple interfaces on the same class.
• TheColonel26: Well I guess the obvious answer would be a just treat entity as storage and forget about using it as a data model, or not use entity all together. I'm slowly figure out how to use multiple interfaces on the same class and how that will work with my data model too. Thanks for the help :)

Answer 2

Yes, this is a general/good practice. See modular programming, separation of concerns and single responsibility principle. These concepts are interrelated but the gist of it is that you should break up your code into independent, single-purpose pieces. This allows you to make changes to the pieces individually without affecting the rest, swap them with similar pieces and reuse them elsewhere. Currently you wouldn't be able to reuse, say, your hardware code in another project that uses a different UI; the parts are said to be tightly coupled.

• TheColonel26: Well the way I usually structure it, I could. I would just have to reference the Hardware Library to get the Class Type for my data, and subscribe to the events that my Hardware API fires, but say I change something in that Data Class Type. I would also have to change that in my UI. Maybe I miss understood what he was telling me or maybe I am miss understanding you.
• Doval: @TheColonel26 Some example code would be handy for understanding what you're currently doing and what you think your senior's solution looks like.