3

I have a project coming up where I'm supposed to upgrade an existing access app to a .net architecture.

I'm wondering how to design object-oriented models from the giant tables and multiple relationships between them in an ERP like system.

For example, if I have an Order object, the orders table alone has 20+ columns where a lot would translate to normal properties, but an order has multiple foreign keys which all map to their own complex objects like items, customers, supplier etc.

Obviously I'm also not super familiar with the database and the tables and fields in detail, so do I just translate every column? Do I try to only do the relevant stuff and fix it later if it turns out I need column/property X after all?

Also, since its an upgrade of an access app, the queries are already written and it would be silly not to reuse them, so no Entity Framework I think? I'm also wondering how to best initialize them from the database.

What I usually end up within these bigger systems is something like this to initialize an order completely: get all orders, get all items, get all customers, get all suppliers -> loop through the orders and add the appropriate item/customer/supplier from the lists.

Improve this question

1 Answer 1

Reset to default
1

An object model != data model. What's more, anything that is similar, let alone based on a data model is not an object model.

So there should be no objects for tables, no properties for columns. It's not needed anyway. If I understand you right, the previous application was an Access application, by which I assume it was just a dumb entry frontend for a bunch of tables.

Just model the requirements, not some business model that you think you should model. If the requirements are to retrieve and display data from tables (and you are not allowed to use off-the-shelf frameworks which already do this), then just model that. Just do Data with a display() method or whatever and a bunch of queries that return Data or collections thereof.

Only create other objects if you have "real" behavior that needs to be there. Only do Order if you need some behavior like processPayment() or whatever that is specific to the Order.

Summary

If you really are supposed to implement only a dumb database/tables entry frontend, you should have minimal coding, no specific objects for the underlying domain. Do specific objects only if you have real behavior that you need to code.

Improve this answer
2
  • That makes sense on some level, but arent really stupid models without any behaviour pretty common? The model itself might not do much, but i still need to validate it and display it or build viewmodels from it. I know its entirely possible to do both of those from simple DataTables, but i feel like its much cleaner to use real dumb models.
    – DFENS
    Commented Jul 27, 2019 at 12:22
  • Yes, dumb data-only objects are unfortunately pretty common. Also, yes it is probably "cleaner" in the Uncle Bob sense. However it just makes your application less maintainable, makes you code things you don't need. Just think about how many things you would need to change if even one data element changes. Probably a handful of classes. Shouldn't things that change together be together?
    – Robert Bräutigam
    Commented Jul 27, 2019 at 16:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.