Stored procedures are bad, they're often slow and approximately as efficient as ordinary client side code.
[The speedup is usually due to the way the client and stored procedure interface is designed and the way transactions are written as short, focused bursts of SQL.]
Stored procedures are one of the worst places to put code. It breaks your application into two languages and platforms according to rules that are often random.
[This question will be downvoted to have a score of about -30 because many, many people feel that stored procedures have magical powers and must be used in spite of the problems they cause.]
Moving all the stored procedure code to the client will make things much easier for everyone.
You'll still have to update the schema and ORM model from time to time. However, schema changes are isolated from ORM changes, allowing some independence between applications and database schema.
You will be able to test, fix, maintain, understand and adapt all those stored procedures as you rewrite them. Your app will run about the same and become much less fragile because you're no longer breaking into two different technologies.
ORM's are not magic, and good database design skills are absolutely essential to making it work.
Also, programs with a lot of client SQL can become slow because of poor thinking about transaction boundaries. One of the reasons stored procedures appear to be fast is that stored procedures force very, very careful design of transactions.
ORM's don't magically force careful transaction design. Transaction design still has to be done just as carefully as it was when writing stored procedures.
so it would have been impossible to switch out to another ORM (not
that we wanted to)).
That seems wrong. A major advantage of the repository pattern is that you hide the data access logic and that it is easily exchangeable.
So far it feels as though I put my business logic in my domain model
and via repositories I would work with the ORM (which ever I chose).
However, if I wanted to continue to use the MDA tool for the ORM part
of the application, the model created here would be very anemic (i.e
not contain any business logic). Similarly if I used Entity framework
(.net) or NHibernate for my ORM it too would be an anemic model.? I am
not sure where you would put the business logic if I just used
NHibernate.
An anemic domain model is considered a bad practice by many, for example by Martin Fowler. You should avoid such a design because such a model leads to procedural design techniques rather than a good object oriented design. You then have data classes and manager/processing classes which means you separated state and behaviour. But an object really should be "state and behaviour".
NHibernate does a great job at persistence ignorance. You can hide away the mapping details in XML or with FluentNHibernate and just write plain POCOs. It's very easy to create a rich domain model with NHibernate. I think you can do that with entity framework and the MDA tool, too. As long as this tool produces partial classes you can extend the generated code pretty easily without having to worry that a new generation might destroy your user-written code.
To cut this long story short. When you use NHibernate, nothing, I repeat nothing, stops you from embracing a rich domain model. I recommend using it with FluentNHibernate and mapping by hand. The mapping code takes only 5 to 10 minutes to write. I suppose that the very same is true for entity framework and that its tools at least create partial classes that are easily extensible.
Am I correct in thinking this way, in other words with DDD all the
business logic in the domain and just use the ORM for persistence via
repositories?
For the most part you are correct. You should have a rich domain model. Especially when things become more and more complex, it's easier to maintain and extend when you've designed it properly. But do keep in mind that DDD also knows (Domain Layer and Application Layer) Services to implement business logic and Factories to encapsulate creational logic.
I also tend to differentiate business logic into domain logic and actual application business logic. The domain logic is how the domain interacts and behaves while the application logic, which is a completely different layer, encapsulates how the domain is used for the specific use-case/application. Often times I have to update the domain model to support specific use cases and to make it more powerful.
Best Answer
I'd wrap your SQL data access calls as stored procedures then, you can expose a different datatype in the sproc results, casting within the procedure if required.
Then your data access becomes like an API, you won't need all the nasty ORM mapping stuff, and just use it to read and write the "DB API" keeping all the internal structure of the DB hidden.