In my last question I posted some sample code on how I was trying to achieve separation of concerns. I received some ok advice, but I still just don’t “get it” and can’t figure out how to design my app to properly separate concerns without designing the next space shuttle.
The site I am working on (slowly converting from old ASP section by section) is moderately sized with several different sections including a store (with ~100 orders per day) and gets a decent amount of traffic (~300k uniques/month). I am the primary developer and there might be at most 2-3 devs that will also work on the system.
With this in mind, I am not sure I need full enterprise level architecture (correct me if i am wrong), but since I will be working on this code for the next few years, I want it to perform well and also be easy to extend as needed. I am learning C# and trying to incorporate best practices from the beginning. The old ASP site was a spaghetti mess and I want to avoid that this time around.
My current stab at doing this ended up being a bunch of DTOs with services that validate and make calls to a DAL layer to persist. It was not intentional, but I think the way it is setup now is a perfect anemic domain model. I have been trying to combat this by turning my BLL to domain objects and only use the DTOs to transfer data between the DAL and BO, but it is just not working. I also had all my dtos/blls split up according to the database tables / functionality (eg – YouTube style app – I have separate DTO/BLL/DAL for segments, videos, files, comments, etc).
From what I have been reading, I need to be at least using repositories and probably interfaces as well. This is great, but I am unsure how to move forward. Please help!
From what I can see you have four points that need addressing:
(1) “With this in mind, I am not sure I need full enterprise level architecture”
Lets deal with the high level fluff first. It depends on what you mean by “full enterprise level architecture”, but the short answer is “Yes” you need to address many aspects of the system (and it will depend on the context of the system as to what the main ones are). If nothing else, the keys ones would be Change and Supportability. You need to structure the application in a way that supports changes in the future (logical and physical separation of concerns (Dependency Injection is a great for the latter); modular design, etc).
(2) “How to properly separate concerns in my architecture without designing a spacecraft?”
I like this approach (it’s an article I wrote that distilled everything I had learnt up to that point) – but here’s the gist:
Looking at this you’ll have a minimum of six assemblies – and that’s not huge. If you can break your system down (separate concerns) into these large buckets it should go a long way to giving what you need.
(3) Detail
Separating concerns into different layers and classes is great but you need to go further than that if you want to be able to effectively deal with change. Dependency Inversion (DI) is a key tool to use here. When I learnt DI it was a hand-rolled affair (as shown in the previous link) but there are lots of frameworks (etc) for it now. If you’re new to DI (and you work in .Net) the article will step you through the basics.
(4) How to move forward
Get a simple vertical slice (UI all the way to the DB) working using DI, etc. As you do this you’ll also be building the bones of the framework (sub-systems and major plumbing) that your system will use.
Having got that working start on a second slice; it’s at this point that you should uncover any places where you’re inadvertently not reusing things you should be – this is the time to change those before you build slices 3,4 and 5 – before there’s too much rework.
Updates for Comments:
I have no idea, but for the answer to be ‘yes’ you’d need to be able to answer these following questions with ‘yes’:
Yes. Projects map 1-to-1 with assemblies, so get the benefits of loose-coupling you’ll definitely want to separate things that way, and be careful how you set references.
DTO not Rich Domain Object. BUT, people seem yo use the terms POCO and DTO interchangeably when strictly speaking they aren’t – if you’re from the Martin Fowler school of thought. In his view a DTO would be a bunch of POCO’s (or other objects(?)) parcelled together for sending “across the wire” so that you only make one call to some external system and not lots of calls.
Managing dependencies. What you don’t want is for you UI to reference the physical data structure because as soon as that changes (and it will) you’ll be (to use the technical term) screwed. This is the whole point of layering. What you want to do is have the UI depend on abstractions – not implementations. In the 5-Layer Architecture the POCOs are safe to use for that because they are an abstract / logical definition of ‘some thing’ (a business concept) and so they should only change if there is a business reason – so in that sense they are fairly stable and safer to depend on.