Architectural conundrum

Question

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?

Answer 1

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).

Answer 2

Such is the danger of having multiple respositories. This raises the immeadiate issue of 'do you need them all or not'? Does it make sense to consolidate any of them, and can you?

I'd advise you to do some reading on Data Architecture - I'm a complete novice myself but I've had some great input from a very experienced one. One view is that Data Architects are more worried about how you data is defined than how the physical database is actually put together: My advice would be to start by capturing and documenting (modeling) the logical data model, and physical ones. Having a really clear understanding of the data will help immensely.

The specific of this (i.e. the bits DA's are worried about) is the definition of the data - what is this bit of data (don't rely on teh column and table names)? How is it used, what does it mean, where is it created? Also important is that we aren't talking about where it's created physically in your system - but where it's created in the business process(es). yes you need to worry about the system - but that's for later; the busines process should drive the system. Thsi is all logical data model stuff.

Once you have the definitions you can start piecing it together - how does the data from the different repositories relate? (possibly more into the physical model here).

Once all that is clear the answers for how you fit it togther in the app should start becoming obvious, and having it documented will help. thsi is once of those instances where having good documentation really is actually essential.

Answer 3

I don't see a problem with this, frankly. Having separate classes for the data in separate layers means that you can change one without having to change the others. The extra cost of the other representations is usually pretty minimal - typing speed is generally not the factor in productivity.

OTOH, being able to change something about data storage without being obligated to change the whole stack can save you a ton of time and effort, as often using the same construct for multiple purposes results in unforeseen side-effects when making a change.

IOW, while having to propagate a change through multiple layers can suck, it can often be assisted by proper tooling, etc. On the other hand, when a trivial change in your data layer has an unforeseen side effect in your UI, that always sucks, and slows any change as anything you do can break anything in the entire system.