1

I'm building a new system from scratch and working on the design of the application. I'm looking at viable approaches for modelling my Domain objects.

Some specifics about the project - this will be a rather large data entry WinForms application, integrated into ESRI ArcMap (a GIS application). The data access must go through ArcMap's own data access layers - The data is retrieved and saved via cursor style access. This is not a problem to get the data, but as far I know, this rules out ORM tools as Entity Framework and NHibernate, as I cannot interact directly with the database.

The WinForms application will follow a MVP Supervising Controller pattern - the View will bind to the Model. The Presenter will also be modifying the Model. So the Domain object should support the following:

  • Change notification
  • Change tracking. At the bare minimum I'd like to know if my model has changed.

My options so far:

  1. Write POCOS by Hand. +Pros/-Cons:
    • +Should be doable
    • +Can accomodate business logic
    • +Bindable
    • -Lots of manual work
      • -Change Notification through the INotifyPropertyChange interface.
      • -Change tracking via an IsDirty property, which must be maintened manually.
  2. ADO.NET DataSets wrapped by POCOs. +Pros/-Cons:
    • +Change notification "for free"
    • +Change tracking "for free"
    • +Bindable
    • -Feels kind of messy

What I have ruled out:

  • Entity Framework - I'm on .net Framework 3.5, so no Code First support. As far as I know, handling domain logic is very messy - event handlers.

Are there any other good options? Perhaps code generation (any suggestions on tools?), some Framework? Words of Wisdom, advice?

Ronald Zarīts
  • 11,819
  • 8
  • 39
  • 42

2 Answers2

0

Read this book It's even more than you have to know

nhaberl
  • 417
  • 1
  • 4
  • 17
0

My POCOs are just "dumb" data transfer objects and they contain no business logic whatsoever. They also aren't my models as they are another set of dumb down objects that are closer to my UI. I just pump my DTOs full of data in my data access layer, pass them up to my service layer for processing business logic, but they are only transferred up to my presenters/controllers to pump just enough information I need in to my UI through models. For your scenario, I think this would be more logical since you have to go through ArcMap's data access layer. You can persist the data in your presentation layer and do change tracking there.

Will Sams
  • 196
  • 2
  • 14