I’m learning to program using C# and ASP.NET with a SQL Server database. I have developed a system to store and view trades taken on a financial market. Basic functionality is:
- Add/Update/Delete an Order
- Add/Update/Delete a Trade (a trade comprises one or more orders)
- View trades
- View orders
There are other entities as well, things like Brokers, Accounts, Strategies, etc that support the main Order and Trade entities.
I have designed my program to have a Database utility class called DBUtil which has all the interfaces to the database. For example to add a new trade I would call DBUtil.InsertTrade(<params>), to add an order DBUtil.InsertOrder(<params>), to update a trade, DBUtil.UpdateTrade(<params>), etc. I was wondering if it would be better to create a Trade class, an Order class, a Broker class, etc. Would that improve the elegance, quality and maintainability of the program? It seems like adding a lot more code for no benefit, well, I can’t see the benefits right now of taking such an approach.
As far as I can see adding a Trade class would simply create an extra layer of code, because I would have to call DBUtil.InsertTrade() from the Trade class anyway when adding a trade, for example.
It really depends on what the application will grow into and who will maintain it.
IF you are happy with it at the minute then why change it.
I would advise you to read up on software development patterns, at the minute it sounds like you are using the Active Record pattern, and that is OK:
http://en.wikipedia.org/wiki/Active_record_pattern
What you are thinking of is moving to a Domain Driven Design solution.
http://en.wikipedia.org/wiki/Domain-driven_design