I’ve not yet found a clear answer to this and to clarify:
With nHibernate and SQL server are you expected to disregard or migrate your business logic stored in your stored procedures, views and triggers into HQL or application code?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’ve not yet found a clear answer to this and to clarify:
With nHibernate and SQL server are you expected to disregard or migrate your business logic stored in your stored procedures, views and triggers into HQL or application code?
Well, leaving aside all details: yes.
NH is an Object-relational mapper, and is intended to be used with an architectural style called ‘Domain-Driven Design’. An important aspect of it is that it completely disregards the database for anything other than saving and loading data – this concept is called Persistence Ignorance, and its motto is: There is no database.
From this point of view, having business logic living in stored procedures or some other db object is not only discouraged, but it would clearly be a severe code smell.
If you follow the preferred Domain-Driven Design methodology, there will be just no opportunity to put business logic into the db – simply because there isn’t any db around at the time of constructing your business layer…