1

This might be a long list of questions but please bear with me. I started building LOB applications with WPF, PRISM, CODE FIRST and SQL CE, and after my first application (or attempt) I have many questions, so to begin with:

  1. Where should business logic go, in the model or in a BLL layer just above the domain layer ?
  2. Should view models receive references to repositories or should repositories be used only by the domain model objects ?
  3. To put the second question in another way, what sort of objects should be given to view models ?
  4. I use the same view model in display (in a data grid for example) and for editing in a form but that causes a lot of trouble, is there a better way to do this without code duplication ?
  5. The biggest problem I have faced was that I always organized my view models in hierarchical relationships without allowing the children in the hierarchy to obtain references to their parents, and since the views bound to those children and invoked methods that caused the addition of objects to the repositories I couldn't find a way to notify the parents of the changes to the those repos. so the bound views could be updated, I have seen some people solve this using events but I don't like this solution and I would like to know if there is a better way to do it ?
  6. Can anyone point to an example of building real life LOB applications using the technologies mentioned above, at least not examples that use VB .NET or WCF (I want local databases).
Hannish
  • 1,482
  • 1
  • 21
  • 33
Ibrahim Najjar
  • 19,178
  • 4
  • 69
  • 95

1 Answers1

1

I'm developing a LOB app right now, with WPF, Entity Framework Code First and SQL CE 4.0 with a local database. I'm not using PRISM, but I'm using MEF as IoC with my own implementation.

  1. So far, I recommend that you use the benefits of Code-First approach and implement as much business logic in your domain classes as possible. Also implement INPC in them. If you don't you'll end up having all your properties duplicated in your ViewModels, which is nonsense. There is no rule that says that the model should be dumb (although some people tend to think so), but a dumb model just makes the ViewModels more tedious to work with.
  2. No clear recommendation here without knowing more of your project, but common sense: try to stick to best practices unless they start coming in your way. "Perfect" is often the enemy of "good".
  3. Let the ViewModel get whatever they need (single model objects, collections, etc.) to serve your views. Often the simpler solution is easier to maintain in the long term.
  4. I don't quite understand what you mean with this... I use my ViewModels several times if possible, but think that a ViewModel's function is to serve a View, if you are having trouble trying to get one VM to work for several Views, it's probable that you need to divide it into two different VM. Just gather all the common properties and methods in a base class and inherit from it as you need.
  5. There are some loose-coupled ways for the VMs to communicate with each other. I'm using MVVM Light Messenger class for such things, but I understand that PRISM provides a similar functionality. It's not a sin to reference the parent from the child if you don't abuse it. I have a ViewModelBase<T> and the child have a reference for their parent pointing to the base class and specifying the T type, a good balance between hard and loose reference so far.
  6. If someone points you to such an example, let me know! Actually, working with a local database should be simpler. In my case I'm using a singleton context (which a lot of people seem to loathe) but since this is a local app, with a single user and no threading complications a singleton context makes my life much easier. I'm still waiting to find a real good reason not to do so with this conditions.

PS: some people will probably downvote your question because... it is not ONE question, and it opens room for a lot of debate. If it gets closed, try the chat.

Hope this helps you, regards!

Hannish
  • 1,482
  • 1
  • 21
  • 33
  • I asked this question 4 months ago and i learned a lot since then, so i agree with most of what you have said except for the context being a singleton, i usually keep it alive for the duration of a form or tab, etc. – Ibrahim Najjar Jun 06 '13 at 13:32
  • Thank you for accepting Sniffer. My case is somewhat special, the all forms share a lot of information and they stay open all the time, so in the end the singleton context made sense for me. As I said before, it's a matter of preference, and I still haven't found a strong drawback for a case like mine. – Hannish Jun 06 '13 at 14:58
  • You are welcome, if it works then don't change it. it might suit me one day who know !. – Ibrahim Najjar Jun 06 '13 at 23:43