CODEWITHSUNDEEP
c#asp.net-mvcentity-frameworkarchitecturedomain-driven-design
Marco Staffoli
Marco Staffoli

Reputation: 2496

Entity Framework DDD using partial class -persistance ignorance -testability

I want to use Entity Framework and autogenerated classes in my application.

I'm not interested on:

I only care about one thing:

I read about Domain Drive Design and I'm interested on it because it claim to simplify complex applications. But when I read code from real application example I get shocked by the complexity of this approach.

My idea is to use partial classes to extend the classes generated from EF. Ther is someone that try this approach and can give me some advice?

Upvotes: 0

Views: 1032

Answers (2)

quentin-starin
quentin-starin

Reputation: 26688

So, if I understand you correctly, you are hoping to use a data access tool, Entity Framework in particular, to help implement your application.

It sounds like you are not in fact interested in doing Domain Driven Design for this project.

I think that's a fine position to be in. DDD incorporates ideas and patterns and tools that are useful outside of DDD.

However, like others, I will caution about going half way down the DDD road. This is especially true with the concept of a Domain Model. Once you begin attempting to implement a true Domain Model, you will practically need the rest of the pieces of DDD in order to make it work for you. You will find that without all the pieces of the DDD puzzle, your application will move towards the anemic domain anti-pattern.

However, if you go into it with the knowledge that you are not doing DDD, just lifting some ideas from it, you can drive right for that "anemic domain model," and it will be a good thing.

I'll be surprised if I don't get downvoted for saying that, but let me explain.

You can take an ORM (EF), take the concept of a Repository (though I prefer to call it a DAO - Data Access Object - to avoid confusion between the two), and implement your application using a standard Layered/Onion Architecture. The bulk of your application logic will go into Services implemented in the Transaction Script style using data classes that directly reflect your database.

This is a time-tested way to build an application. It is not DDD. The two methodologies fit different types of better, have different pros and cons, etc.

Using EF or a similar tool should make implementing large parts of your application simple and quick. Just don't get bogged down trying to do DDD when you're not really doing DDD.

Upvotes: 3

Preet Sangha
Preet Sangha

Reputation: 65546

I think you are using a technology without understanding why it's good or bad. In my experience this nearly always leads to bad application design.

Anyone who says they're not interested in testing is sleepwalking into a mountain of problems later on down the road.

The 'simplicity' of DDD comes at the cost of all simplicity, layers of abstraction. Read Eric Evans Domain Driven Design and then you may realise why it leads to better designs.

Personally I think you will lose in this equation. You are a profession you should consider the implication of the terms 'do not consider testing'. What happens if the application breaks if you ever get it to customers? Who will the boss blame? Themselves? Be very very careful.

Upvotes: 1

Related Questions