I am trying to get a feel for how the majority of you out there in the real world structure your code. For the sake of this conversation let’s contemplate a WCF solution with services. My structure often looks like this:
- Service implementation
- Dependency Injection configuration, Automapper configuration
- Mostly authentication/authorization logic
- Defers subsequently to objects from the Business project.
- Take “Manager” classes as dependencies via constructor
- Service interface
- request/response objects, DTOs
- “Manager” classes
- A gateway to all business operations. i.e. TransactionManager.AddTransaction(Trade t). The same class will also have internal methods such as TransactionManager.ValidateTradeForInsert(Trade t), etc.
- Take Repositories as dependencies via constructor
- Ultimately all share the same EF context per WCF request so multiple Manager classes and cross all of their repositories perform one unit of work with one ultimate SaveChanges().
- Entity Framework
- Generic repository which allows basic operations on any of the entities. i.e. IGenericRepository<Person>
- Custom respositories with more complex linq queries not offered by the generic repository, custom ADO.NET, etc.
- POCO entities (generated from db tables)
- Other “skinny” objects that are a result of some business logic.
I mention real world because it’s very easy to get bogged down and unsure of oneself as one starts digging deep into more structured concepts like proper domain-driven-design (seems to come up in every OOP related thread), anemic data model concerns, and even certain OOP concepts. I’ve attempted to read up on domain-driven-design several times over the years and while some concepts I grasped they never really translated well for me into the real world for one reason or another.
Some observations/concerns in no particular order:
- I find it far easier (less work, more flexibility) to create as many repositories as I need (ie one per table) because of the generic repository than creating aggregate root type access preached by DDD.
- I have clear separation between manager objects and entities. So basically the absolute definition of anemic data model at least from first glance. For example if a prerequisite to adding a person is to check that there isn’t such person already in the database, the validate method will live in the PersonManager as opposed to Person entity, because the manager is the one with access to the repository for querying.
- Even though I have a clear separation between entities and eventual DTOs, the reality is 95% of them are 1:1 mappings.
- I don’t end up with too much “sophisticated” OOP concepts here. It’s cut and dry, basic if you will. I always find it far easier to create “pretty” or “textbook” OOP solution when working on something that isn’t highly data driven. For example a utility of sorts.
Just looking for some general conversation on this topic I suppose, looking for people to share their thoughts and experiences laying out/designing highly data driven applications.
by ChosenGSR via /r/csharp