2

I am working on a new three-layered .net/WPF application. The application will do a lot more than just CRUD, but it does CRUD too. I'm finding that there's a ton of redundant work that needs to be done when setting up a new CRUDdy entity; say, a Person:

  • In the data access assembly, create a PersonDocument class that is structured and marked up with attributes in a way that allows our in-house document storage system to persist it
  • But I don't want to expose PersonDocument to the upper layers since that would leak information about the persistence mechanism. So the DAL also needs a public IPerson and code to adapt a PersonDocument into an IPerson
  • The DAL needs to expose a PersonRepository so the upper layers can do CRUDs with IPersons
  • The business layer needs to provide information about persons to the presentation layer, but the presentation layer isn't supposed to know about the data access layers or it types. So the BL assembly needs its own IPerson. This is probably not exactly like the DAL IPerson--in particular, the DAL IPerson is going to be almost 100% anemic (data only), while the BL IPerson will contain a bunch of operations relating to the business actions you might want to take with a person. But it will be pretty close, and with some simple entities, perhaps exactly the same.
  • More mapping code will be needed to go back and forth between a DAL IPerson and a BL IPerson
  • The BL will need its own PersonRepository over BL IPersons for use by the presentation layer

Now imagine that I decide I want to start tracking the age of every person I store. I'll need to:

  1. Add an age property to the DAL's person document
  2. Add an age property to the DAL's IPerson and its implementation(s)
  3. Update the code that translates a PersonDocument into a DAL IPerson
  4. Update the code that translates a DAL IPerson into a PersonDocument
  5. Add an age property to the BL IPerson and its implementation(s)
  6. Update the code that translates a DAL IPerson into a BL IPerson
  7. Update the code that translates a BL IPerson into a DAL IPerson
  8. Finally, I can update the databindings in presentation to display age

Something like AutoMapper could maybe ease the pain in 3, 4, 6, and 7 if I invest the time to learn to use it, but the amount of work involved here still seems to be telling me I have a bad design. Is this just the way it goes with 3-layer architecture, or am I missing the point?

dlf
  • 9,045
  • 4
  • 32
  • 58
  • 1
    This feels like exactly the sort of whiteboard question that would fit really well at Programmers.stackexchange.com. – Paul Turner Sep 03 '15 at 13:29
  • Before deciding on such a complicated architecture you probably should formulate exactly the benefits that you are going to derive from it. For example, what benefit will it bring you that the UI layer does not reference the DAL? The DAL is *not* meant to be replaced. – usr Sep 03 '15 at 13:39
  • @usr It allows us to deploy business/data on one tier and the UI on another, as will be necessary when/if the word comes down that a mobile version of the app is needed – dlf Sep 03 '15 at 13:42
  • 2
    @Tragedian when referring other sites, it is often helpful to point that [cross-posting is frowned upon](http://meta.stackexchange.com/tags/cross-posting/info) – gnat Sep 03 '15 at 13:58
  • I'm voting to close this question as off-topic because, whilst being a good question, it is a **software design** problem rather than a programming problem. – Paul Turner Sep 03 '15 at 15:21
  • @Tragedian actually the right thing would be to contact a moderator and ask him to move it – Dbl Sep 04 '15 at 09:27

0 Answers0