I'm working in a project that use nhibernate as orm. Is there any benefit for me to use sharp architecture? what is these benefits?
C# – the benefit of using sharp architecture
cnhibernateorm
Related Solutions
(Almost) all applications benefit from ORM.
First, I don't agree with the advantages you list for ORM.
- Using ORM doesn't necessarily mean you don't need to know SQL. A knowledge of SQL will help understand what the ORM tool is actually doing, which is especially useful during debugging. Moreover, SQL may actually be required to develop complex queries that are beyond the capability of your chosen ORM.
- And as you say, portability is rarely a concern in real life.
Instead, the real benefits of ORM are:
- ORM saves programmer time because it saves writing tons of CRUD logic in SQL
- many ORMs include complex caching logic etc. that is difficult to write and debug. As well as saving time this can enhance reliability and maintainability of your application (or at least save you the time it would take you to achieve the same results)
- the best ORMs have a community of users who actively develop, maintain and support the product. The community around custom SQL is, at best, somewhat less focused on the problems we need to solve.
As you comment, one down side of ORM is a loss of performance. However, this can usually be offset by spending more hardware.
Typically, programmer time is more expensive that hardware, so ORM is genrally a good option instead of hand-coding SQL.
ORM is best for applciations with a lot of fairly simple CRUD database logic. ORM is less effective for:
- Applications that need little / no database access.
- Applications that are largely dependent on complex queries and very little simple CRUD logic
- Situations where performance is critical, but where there is no possibility of deploying faster hardware
In my experience, these situations are rare. Hence my answer.
My personal "frequently explained" issues:
Anti-Patterns
Messing around with detached objects (SaveOrUpdate or Merge plus some messy code) instead of using DTO's. The more complex the entities are, the messier the code is. (It also means that it works quite well with trivial entities.) Ayende also calls it the Stripper Pattern and explains the encapsulation issue.
Not understanding persistence ignorance and writing NH applications as when using explicit SQL. Symptom of that: calling Update after changing an object, wondering why changes are persisted even if Update had not been called, wondering how to avoid changes to be persisted.
- I tried to explain it in this SO answer
- Read how flushing works in the reference documentation.
- A blog post by kurtharriger who is criticizing exactly what is actually one of the main features (as a prove that it is a common misconception about NH)
Not understanding transactions and the unit of work pattern. Frequent anti-patterns: implicit transactions, session-per-operation and session-per-application. Some more reading:
- Fabio Maulo: Conversation-per-Business-Transaction
- On nhforge.org: Effective NHibernate Session management for web apps
Using NH events to put application logic in (eg. change tracking in insert and update triggers)
Create one class per table. Some people don't understand OOD, others don't understand relational design.
Mistakes
use of one-to-one instead of many-to-one. I tried it to explain in this answer.
Using join fetch in combination with SetMaxResult. My latest answers related to that topic:
- Why doesnt NHibernate eager fetch my data (with some more notes about side effects in the comments)
- Hibernate - How to make associations eager
- NHIbernate 1.2 And Lazy Loading
- Pagination with Hibernate criteria and FetchMode.JOIN
Writing self changing entities. When an entity doesn't exactly return the value that had been set by NH, it is considered dirty and gets updated in every session. For instance: replacing the NH persistent collection in a property setter.
IList<Address> Addresses
{
get { return addresses; }
// will cause the addresses collection to be built up from scratch
// in the database in every session, even when just reading the entity.
set { addresses = new List<Address>(value); }
}
int Whatever
{
// will make the entity dirty after reading negative values from the db.
// this causes unexpected updates after just reading the entity.
get { if (whatever < 0) return 0; }
set { whatever = value; }
}
May be more is following.
Best Answer
Mostly, the benefits are that a few conventions that support domain driven design, dependency injection, and loosely-coupled architecture are pre-wired for you so that you don't have to give as much thought to how to accomplish some basic things that would likely result in boilerplate code, false starts, and distractions.
Concrete examples of usefulness: The reasonable base class for a generic repository and a pre-extracted generic repository interface, an overridable but pre-written hook to a sensible dependency injection mechanism, an attribute based unit-of-work transaction scope, some additional model validations that you won't have to write yourself, just to name a few.
There are good arguments for some different choices than SharpArchitecture made, but if you don't have a strong justification for approaches that are dramatically different than SharpArchitecture puts in place for you, you can get up and running quite a bit faster than if you had to implement everything SharpArchitecture has already done.