What will you be doing with the database? How application will be using it? If you want just a mapping 1:1 between database schema and your domain classes then a simpler data access lib may work well without too much overhead. But in the case if you want your domain have a better, usable and more application/UI friendly shape, then you probably want a flexible ORM (NHibernate) to help handle that. Also, how much data & users you will have? If the load will be low, you can probably go by with a quickly put homegrown solution. Otherwise NH will help you to fine tune your mappings & persistence. Valeriu Date: Tue, 11 Jun 2013 19:00:42 -0700 From: [email protected] To: [email protected] Subject: [nhusers] Seeking advice on whether I should use NHibernate for my current task
I am needing to rewrite an old application written in vba (access) in .net; Unfortunately, since all of our clients use it, and it may be necessary to release the new application in stages, I can not change the underlying database, at this time (as the existing functionality not being superceded in staged releases will still use it). This database is awful (tragic!) in a number of ways: many tables lack an identity column & varchar primary keys are common. In some tables, the primary key is a single varchar column, but logically it should be two (or more) such columns. a fair number have composite keys which may include varchar column(s) the database has no defined relationships, though tables are easily joined in SQL queries; in most cases names of foreign key columns (ie columns which would be foreign keys if relationships where defined) are the same as the primary key columns of the relevant master tables, but there are a fair number of exceptions to this rule too. many tables have significant denormalisation, for example our person table contains three complete sets of address and contact information (being 3 lots of 4 address line columns, 3 postcodes, 3 phone number columns, 3 email address columns + more), and there is a column to denote which is effectively the primary set of contact information for that person. various tables have columns which are references to themselves (eg Person.ManagerCode is the ID of another person row). I've browsed through about a third of the NHibernate reference information (3.3) trying to get a grip on answering this question, but hell there's a lot of info in there, and I can't apply what I've read even to answer whether it is really going to be a better approach than just building a primitive DAL engine which plugs values of controls into stored procedure parameters and runs stored procedures for crud operations. (Using this approach, the underlying data model can be changed later without affecting the application, given the rewriting of affected stored procedures - though that is unlikely to be a small task) Hence I'd like to ask for advice. Any answers/comments would be greatly appreciated. If you'd recommend that NHibernate is the way to go, feel free to suggest any logical starting points. Thanks in advance... -- You received this message because you are subscribed to the Google Groups "nhusers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nhusers?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nhusers?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
