So recently I decided to look up what all this "design pattern" stuff was all about. I'm particularly interested in Microsoft's M-V-VM pattern as I intend to use WPF for my interface. Clearly I need to rethink my business objects a little since there is a new level of abstraction introduced that I have never considered before.
For example, my Customer object is obviously intended to edit customer data. However, I know that on my customer edit form I'm going to display a list of active quotes, active projects, and any other useful information about the customer that the users might want at their fingertips. Currently, my Customer object contains these lists as properties. The fact that it is necessary to fully conceptualize what my edit form is going to look like before I can finish my business object is a clear indication that I'm doing something wrong.
So my question is, instead of having this object hierarchy in the business layer:
Customer, Customer.Quotes, Customer.Projects,
have the Customer object and 2 lists as completely separate entities in the business layer and instead create a viewmodel object in the UI that takes 3 separate entities and creates a user interface specific object heirarchy such as:
CustomerVM, CustomerVM.Quotes, CustomerVM.Projects? This design pattern stuff is all new to me so any suggestions/hints/tips would be greatly appreciated. Thanks in advance.
beerisgood:
So recently I decided to look up what all this "design pattern" stuff was all about. I'm particularly interested in Microsoft's M-V-VM pattern as I intend to use WPF for my interface. Clearly I need to rethink my business objects a little since there is a new level of abstraction introduced that I have never considered before.
For example, my Customer object is obviously intended to edit customer data. However, I know that on my customer edit form I'm going to display a list of active quotes, active projects, and any other useful information about the customer that the users might want at their fingertips. Currently, my Customer object contains these lists as properties. The fact that it is necessary to fully conceptualize what my edit form is going to look like before I can finish my business object is a clear indication that I'm doing something wrong.
I would agree; it sounds like your should seperately be able to get a list of active quotes, project, etc. The fact that you've combined them into a dashboard shouldn't matter. Now, if you want to get all the data in one go, you could create a command object that fetches the relevant BOs.
So my question is, instead of having this object hierarchy in the business layer:Customer, Customer.Quotes, Customer.Projects,
have the Customer object and 2 lists as completely separate entities in the business layer and instead create a viewmodel object in the UI that takes 3 separate entities and creates a user interface specific object heirarchy such as:
CustomerVM, CustomerVM.Quotes, CustomerVM.Projects? This design pattern stuff is all new to me so any suggestions/hints/tips would be greatly appreciated. Thanks in advance.
Well, I'm not totally familar with MVVM, but I would think that's a better way to go. This particular Wpf UI uses all those BOs, but another may not. So it makes sense that the UI layer has a component that knows how to fetch all the data (or would contain the above mentioned command object).
I'm actually doing something like this now; the part edit screen should display orders for said part, but my BOs aren't designed around that. One of the nice things is that the UI can display the part and it's data, while the grid is off loading it's data asyncronously.
Background loading and snappy UIs are important to me. Now that we have multicore processors, putting as much onto background threads as possible makes sense.
HTH
Copyright (c) Marimer LLC