The worst thing when working on a one man project is the lack of input that you usually get from your coworkers. And because of the lack of that you tend to make obvious mistakes.
After going down that road for some time I would need some help from the community.
I started a little home-brew project that should turn into a portal of some sorts. And the main thing that is bothering me is the persistence layer that i have concocted. It should be completely separated from the presentation layer for starters and a OR mapper is also somewhere. This is because I have multiple data stores that have to be used.
So the base idea was that the individual "repositories" operate each on their individual database and that the business layer then aggregates the business objects which are then transformed in the presentation layer into view objects.
The main problem I face is the following:
Multiple classes for the same concept - There is a DAL representation of a user and BL representation of user and a view representation of a user. I can handle the transformation with a tool but is this really the right way. I mean they are all nicely separated, but the overhead is quite something.
What do you think? Am I going too deep into the separation of concern rabbit hole or is this still normal?
This is more than normal.
Usually no one does this and cries about ORM lazy loading issues when rendering html or whatnot.
It's easier to write DTO layer than to think about DA, BLL and UI simultaneously. Some go even further and apply command & query separation in architectural scale clearly drawing line between input/output (that solves problems like need for artificial business object that actually is used for reporting purposes only).
On the other hand - it depends. If your app is going to be simple, you might not need so much abstraction (e.g. simple company portfolio home page).