Develop Reference

NHibernate (or other worth recommendation ORM), real life example?

I'd like to learn database applications in C# and I'm about to select some framework. I heard many recommendations of NHibernate, however I haven't decided yet.
Anyway, I'd like to know if there's any real-life example (with sources) of NHibernate in C#, to learn best practices etc.? I know all of them are probably covered in the docs, but working example helps a lot understanding the proper development pattern.

Check out Ayende#Rahien, there's a lot of blog entries on NHibernate there. Another good source is NHibernate Forge. To get you started this would be especially helpful: NHibernate Getting Started Guide. Finally here you can find a downloadable working example of a NHibernate project based on the Northwind database.

The open source project S#arp Architecture is so far the best example I'm aware of for NHibernate:
S#arp Architecture
Even if it feels sometimes a little bit overdesigned, it follows best practices in implementing NHibernate in a multi-tier architecture.
I personally learned a lot about ORMs and good loosely coupled architecture going through
the code of the project.
Another worthwhile article about NHibernate can be found on CodeProject:
NHibernate Best Practices

Real life example: Orchard uses NHibernate, Fluent NHibernate and Linq To NHibernate for data access. It is an opensource CMS build by Microsofties. Source code is available at CodePlex.

NHibernate is a very solid ORM which allows you to create POCO classes, keeping your domain model very clean and allowing easier testability.
Entity Framework is improving rapidly. The UI tools in EF4 are okay for small applications but it is difficult to manage that kind of development with version control, rapidly changing DB schema etc. With EF4 Code First approach (in CTP stage at the moment) EF4 will will be much more attractive.
I have used LLBLGen in past with great success.
For beginners, Webmatrix can get you started very quickly. Check Rob Connery's video on how to use it with testing framework here

As others have said, NHibernate is a solid framework to work with. It's quite mature and has a lot of features that let you control exactly what will happen to your date.
That said if you're just starting out with database programming you may also want to consider LinqToSql. It's not nearly as powerful as NHibernate, and it has been more or less EOLed. However, what you give up in power you gain in simplicity. It will allow you to get a basic database application up and running probably within minutes and allow you to experiment as you first learn. Despite the simplicity of getting your first app up and running it's still powerful enough to be used to build something like Stack Overflow.
Some good Linq to Sql beginner resources:
NerdDinner
ScottGu's series: Using LINQ to SQL (link is to part 9 because that has links to 1 through 8 at the top). Although this one doesn't have an application download (best I can tell) it basically walks you through building an app.
If you have your heart set on learning NHibernate, you can also start with the NerdDinner tutorial linked above and take a look at Ayende's writeup on porting it to NHibernate as well as a series on mapping NerdDinner with NHibernate. There's also a series of articles on using NHibernate in a WPF application (most other tutorials focus on web apps).
Resources:
Ayende's Reviewing NerdDinner and Reviewing NerdDinner: The Select N+1 pitfall
NerdDinner with Fluent NHibernate Part 1 - The domain model
NHibernate and WPF (again, links to part 4 that has link to parts 1 - 3).
One thing I can't emphasize enough is once you get past the initial "cool...I can talk to the DB" phase, grab a trial license for an appropriate profiler (list of profilers at the top) for your platform. It will let you see what exactly your ORM is sending to the DB. It can be very valuable for learning how what you're doing gets translated into SQL as well as troubleshooting bugs you run into.
Regardless of which path you choose you should also take a look at Data Access Practices Using Microsoft .Net: A Nerdly Comparison and Data Development GPS: Guidance for Choosing the Right Data Access Technology for Your Application Today. Although those only cover Microsoft technologies, it'll give you a high level overview of what's available out there and when it may and may not be appropriate for your projects (in the future).

Take a look at NHibernate addins project http://code.google.com/p/unhaddins/
Though this is not real life production example, the sample applications there are pretty close to real life applications | scenarios. The examples there are written by well known and respected programmers and they show some serious OOP and design patterns skills. This is definitely not for beginners.

Using MS Access as a .NET Application Backend [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am the lone .NET developer in an non-IT organization. I've been asked to develo ae .NET application using Microsoft Access as the back-end (existing DB).
I don't know where to start.
Since I'm developing by myself, what should I keep in mind to avoid during development? What situations does only a lone developer face?
Please include Microsoft Access specific advice in your answer, since that is germane to the question.

Where to start?
Choose a development environment (I would suggest Visual Studio 2008 Express or Professional, depending on the budget and the need for features of the Professional version)
Even for one single developer: choose a Version control system !!!! (Subversion has only little administrative overhead, fine for one developer)
Choose a .NET Framework version (3.5 is fine unless your application has to run on Win2K; for Win2K use .NET 2.0)
Choose a mature programming language (C# or VB.NET, what you or your boss likes best)
Choose a GUI technology (for a single developer, I would suggest using WinForms, unless you are going to write a Web application or a command line utility)
Choose a mature DB access technology (ADO.NET works for a lot of things, unless you have very high performance requirements that are better dealt with old ADO/OleDB or DAO)
EDIT: use Google to find some entry examples according to the choosen technology, or buy yourself a book. For example, here is one for C# using OLE DB to access a MS Access DB. This Access site is a good starting point, too.
EDIT2: make yourself familiar with "Microsoft Access" (the Office Application). Not because you are going to use it like a typical user, but you will probably need it for administrative purposes. And the VBA & SQL documentation included will be sometimes helpful, even if you code with C# or VB.NET
EDIT3: for reporting purposes, choose a reporting technology. There are plenty of possibilites here, depending on your needs, your skills and/or budget, for example
Plain ASCII or CSV reports (coded by hand)
HTML or XML reports
using Excel as reporting engine
using a PDF library like Report.NET
using a third party tool like Crystal Reports
You will find a lot of helpful links when you give "report generation .net" to Google, for example this one.
And finally: come back to SO and ask more concrete questions when you come to the point where you have them.
There might be other constraints, depending on what code is already existing in your organization. And I would avoid technologies like F#, WPF or Linq to Entities.

Your question is too vague to give more than just general advice. If you have already developed other .Net applications, then the approach to developing this new application should not really be any different.
Database considerations:
The only things to bear in mind when using MS Access as a back-end database are:
Scalability - MS Access does not
scale very well and is only suitable
for a small number of users
*EDIT: Numbers vary depending on the type of activity the users are performing - for a reporting solution, Microsoft themselves suggest that up to ~100 concurrent users is the maximum - this white paper provides more information *
Security - MS Access does not offer the same sophisticated levels
of security that you will find in
other database products (SQL Server,
Oracle, MySQL)
SQL Syntax - there are some subtle differences in the way you
write certain types of query for MS
Access
Other Limitations - MS Access does not support stored procedures, so all your data access code will have to use inline SQL Commands (command.Type = CommandType.Text)
The maximum database size supported by Microsoft Access is 2GB - keep an eye on the growth of the database
Design considerations:
Does the existing MS Access database already have some user forms and code modules in it? If so, you could use these as the basis for your application - MS Access uses Visual Basic for Applications (VBA) as it's programming language and there are no tools/utilities that I know of that will port VBA to VB.Net
Do similar applications exist elsewhere that could help inform your design?
Keep data access code out of your forms as much as possible - try to keep data access code in a separate class/DLL so that it is easier to maintain
EDIT: as others have suggested, try to avoid having instances of ADO.Net connection and command objects scattered throughout the user interface - put all database connection code in one class/DLL so that it easier to fix/maintain/replace. I'd also suggest putting all your SQL query statements in a separate class or module for the same reason. *
Follow any in-house guidelines that you, or others before you, have put in place.
Keep maintainability in mind - someone after you may have to make changes. Use comments in code and give your objects (forms/variables/function names) sensible names
Take regular backups of your code - put a copy on a network drive or USB drive every day

One point of advice, encapsulate all Access-specific code within a single class. The class should at least be able to:
locate the Access .mdb file
create and open all OleDbConnection objects
It's critical that all Connections are guaranteed to close, so wrapping their use in a using block is a very good idea
(Possibly) build and execute all OleDbCommands (removing the db-specific logic from the consuming components--they should be able to make data-requests and retrieve results while transparently creating the Connection & Command, etc.

For accessing the Access database, you could maybe have a look at NHibernate? As far as I know it supports Microsoft Access and using a library like that could perhaps make things easier if you are going to move the data to some other kind of database later on.

If you are already familiar with a .NET language and MS Access then my advice would be to start off by developing a very simple MS Access database and write a small .NET console application that connects to that database and performs some basic functions e.g. querying/inserting/deleting/updating. Then its just a case of builiding on top of this piece by peice, introducing GUIs/separate libs (dlls) etc on the way.
Unfortunately for you .NET Linq to SQL (ORM) does not support MS Access databases so you will have to develop your Business Objects from scratch (not always a bad thing!).
Here is a good starting point MS Application with C#.

There is a lot of good advice here, all I would add is be sure to build all your data access and modifying classes behind a well defined interface(s). I am sure there will come a time when this application out grows MS Access and having well defined interfaces will make upgrading to another database easier.

DataSets based .NET programme: Use Designer tools or do it self?

After thinking for long, I have decided to build my data app for the Not-for-profit organization I work for (I don't program regularly there, though...) using C#, .NET 3.5 (using ADO.NET DataSets) and Scimore db.
I have done base basic tinkering till now and have found this combo to be quite good and fast. Ya, "fast" is a requirement for me, as our computers are slow.
I have a question though: should I use Visual Studio design tools to help me build my GUI for data bound controls or should I code them by hand? In simple scenarios, I have found that designer generated code seems to be too big for the purpose.
Will it somehow affect the "fastness" of my final app?
Thanks for reading!
Edit Sorry, I didn't mention, this would be a desktop application, using Winforms

Usually the amount of code does not affect execution speed so I shouldn't worry about that. Therefore, you should consider using the Visual Studio design tools for building your GUI. Most of the time you can build your application a lot faster this way.

if you're looking to keep your ASP.NET code as lightweight and fast as possible you may want to look at using ASP.NET MVC. This is the technology used to create StackOverflow, it gives you a lot of control over which data technologies you want to use to implement your site, and it for the most part avoids the overhead of using ASP.NET server controls. You may find this to be a great option for your needs.

Is Codesmith a viable ORM tool (or should I stick with a true ORM) [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I'm shopping for an ORM tool. I'm agonizing over the purchase of either CodeSmith (which is currently available at a substantial discount) versus an ORM tool.
LINQ to SQL is off my list; SubSonic 2.x is off the list (I don't want to invest in that dead end knowing that SubSonic 3.0 is coming. NHibernate seems like overkill as does LLBLGEN. I've only briefly evaluated EF but don't get quickly get a warm and fuzzy feeling from it.
Am I crazy thinking that CodeSmith is a rational alternative to off-the-shelf ORMs? Will CodeSmith pay for itself in other ways?
Please note that I am in no way related to any vendors and this isn't a cheap shot SO question just for the sake of generating product noise! I am looking for honest advice and opinions about CodeSmith as an ORM tool (with its provided, or community available) templates.

In fact, hibernate is a good ORM tool. But it stops there!
Code smith capabilities can be more than just a relational mapping staff! I use code smith to generate some UI forms, business layers (templates), data access layers, patterns, and so on.
But to work with code smith, you may need good experience with system design or use their templates which I don’t like to use but I like as an example.
Code smith approach has one special drawback; you have to design your system considering the database implementation first. Nowadays, in object analysis approach, people success in implementing business logic & entities just before any database implementation – they forget about this.
Decision is hard; I've constantly read important names such as Scott W. Ambler, Kent beck, Robert C. Martin and people from The Pragmatic Programmers series which recommends ORM Tool to speed up development. They said that ORM Tool developers are concerned with all database issues (pooling, connections, database vendor specifics, etc). So when we have to design data access layers we have to consider all these aspects too.
I believe that these ORM tools come along with an overburden. I don't know yet how these tools would behaviour in low budget projects (I mean not good hosting servers or any kind of shared resources).
I’ve seen inexperienced developers not taking this into account as they try to evangelise their beloved tools. But in java projects, hibernate is already a widespread and well-known tool. I have no doubt the great projects has been delivered using this technology but I have seen anyone and again java developers may need to teach us (.net developers) how to build great solutions. (Sorry, we have to admit.)
The only thing I would recommend is to consider your context. Are you doing a new system? You need work in pattern? Have you ever try to consider such code generator and ORM tools altogether?
I do prefer code smith because I generate entire solutions at once, not just data access layer. Code generation is very important and it is not for less that Microsoft has imitated code smith approach in visual studio.net 2008 and so on.
Good luck

Code Smith is not an ORM, it's just a code generator IDE.
You can generate a DAL using code smith based off your database but that would defeat (one of) the purposes of using an ORM which is basically that it generates the DAL dynamically so you don't have to write the code.
If you're really trying to compare the two, then maybe you might get some benefit using code smith because you would have absolute control over the code that gets generated, but I'm not sure that benefit would outweight the drawback of what could turn out to be spending months to write the code smith templates to generate a DAL based off your database.
And then you have to considering what happens when you make a change to your database, you will most likely have to run code smith and build everytime you do so. A good ORM will allow you to configure your database changes in schema, and then it will generate dynamically so you don't have to worry (as much) about making changes to the database.

NHibernate is the way to go. It is an enterprise-grade ORM. And with the convention-based auto-configuration from the FluentNHibernate library, configuration is ridiculously simple if you stick to a single convention (you get to specify the conventions, or there are defaults).
With NHibernate, your domain objects are pure C# objects. No weird base classes. No codegenned files that need to get refreshed every time you decide to make a change.

I use netTiers daily and love it. Documentation for it sucks, but it has been such a time saver for me at the office. A lot of people gripe about the amount of code it produces, but from what I've seen, the code it creates is a lot faster than hand coding much of it. It also generates all the sprocs you will need for your basic CRUD stuff. The access methods it produces are pretty awesome as well, getting by all your unique keys, foreign keys and primary keys.

I think the usage of Codesmith is viable. But you should look into frameworks that use it. Net Tiers is an application framework that can be built upon to knock out a good DAL.

Why would something like LLblgen be overkill ? We use it at work, and after a somewhat steep learning curve, it's very nice :). You should at least give that and nhibernate a try.
Not sure what this has to do with codesmith though, thats a codegenerator, you could roll your own ORM, but since there are already good ones out there, I dont think it's worth the time and effort unless you want to do it for learning purposes.

Go with netTiers and .netMVP. NetTiers is a very nice DAL and .netMVP is a framework I just released to support abstraction at the UI level. :)
http://community.codesmithtools.com/CodeSmith/m/templates/42499.aspx

I used LLblgen several years ago. I hope what I saw has been fixed. We looked at the in-line SQL that was produced and saw, for selecting one row of data with the primary key passed in:
SELECT DISTINCT * FROM TABLE WHERE primark_key_id = #primarykey.
Really, DISTINCT? I always begged to do store procs instead, but what shot down by the project leader. I am not sure what time was saved by writing inefficient code.

Good Features for an ORM

I'm currently working on putting together a fairly simple ORM tool to serve as a framework for various web projects for a client. Most of the projects are internal and will not require massive amounts of concurrency and all will go against SQL Server. I've suggested that they go with ORM tools like SubSonic, NHibernate, and a number of other open source projects out there, but for maintainability and flexibility reasons they want to create something custom. So my question is this: What are some features that I should make sure to include in this ORM tool? BTW, I'll be using MyGeneration to do the code generation templates.

For the love of all that's holy (and the women and the children), do everything possible to convince them not to go with a custom O/RM solution. Why are people wanting to re-invent the wheel when there are perfectly-good, open-source wheels already in existence?!?!

If your client isn't interested in OSS because of (real or imagined) perceptions about support, have you considered any of the top-quality commercial third-party ORMs such as LightSpeed that comes with a nice GUI designer tool
(source: mindscape.co.nz)
Mindscape (the company that sells LightSpeed) is a New Zealand company based near where I live, I have met some of the devs there, and I know they are famous for having incredible customer support. And they give you the source code when you buy the software, so you can tweak it any way you like.
You probably don't want to have to roll your own ORM unless you have to and your client is willing to hand over a stupid amount of cash for you to do so.

IMO writing your own OR/M is one the worst design decisions you could ever make. "maintainability and flexibility" are reasons exactly NOT to write your own OR/M.
Please read See 25 Reasons Not To Write Your Own Object Relational Mapper, and see if your client really wants to pay what it costs to build something like NHibernate ($7.6M) or SubSonic ($1.5M). Because, like ChanChan said above, you will end up with something similar to that.

There's a bunch of posts by Davy Brion (an NHibernate committer) who is for some reason also forced to write a custom ORM for a client.
Some of the things he covers are:
Mapping Classes To Tables
Out Of The Box CRUD Functionality
Hydrating Entities
Session Level Cache
Executing Custom Queries
Definately worth checking out, if you MUST go down this path: Build Your Own Data Access Layer Series

You need to go the nHibernate style, in my experience, and have it so that you have some kind of map, between your objects and the database. This allows your objects to have some things that are hard to represent in a database but are easier represented in POCOs.
Generation gets you started, by giving you classes that meet your schema, but if you plan on maintaining anything or testing anything, mapping is pain now for pleasure later.
Subsonic is a great model, and its open source, if you must go generation, use their templates in myGeneration to get a leg up.
BTW: I've done what you are doing, and I ended up with something very similar to subsonic, and now advise my clients to take the subsonic source, and fork it for themselves.

Maybe just maybe, you need badly some "features" that do not exist yet in the existing solutions. Maybe you need something simpler also. 1.5$ for Subsonic is simply outrageous.
Maybe you want to use POCO. Maybe you want to use the stuff easily in a 3 tier scenario.
Maybe you don't want to support ALL RDBMS on the planet, so you can hardcode and optimize the code just for your target. Maybe you want to implement smarter object tracking. Maybe some design decisions made by the existing orms drive you crazy....
I myself am using a custom orm developed by me myself and i, and i am satisfied that i did it. There is no hidden dragon under the carpet, no surprise scenario. My orm does exacty what i want it to do, nothing less, nothing more.

Second level cache
Allows you maintain entities instances in-memory
Automatic dirty-checking
Allows you updates changes in an object without loading it.
Powerful query language
Powerful cascade operation
Powerful primary key generator strategy
ORM framework will pickup best primary key generator strategy according to target database
Support to composite elements
Support to events
onSave, onUpdate and so on
Good documentation and reference books
Support to conversational state
regards,

No-one has mentioned it yet; but go with LLBLGen. You may customise the template as you like, and you may also, obviously, write your own custom code in the generated classes. Buy it. You will never look back, and you will be saying "Thank you silky!" when it consistently works beautifully. (I didn't write it, but I love it). If it doesn't work out for you, you may also say "Damn you silky!". But that's unlikely, however I do offer it as an option.
The only bad thing I noticed about LLBLGen has been the support for switching between Databases/servers on the fly. It doesn't support a feature that I'd like; namely the ability to detect that a given entity you retrieved doesn't "exist" in a new database that you've switched to. But this is a rare case.
I suggest LLBLGen, because I was in the process of writing my own OR/M when I came across it. Never looked back.

Your job as a consultant (sounds like that's what you are) is to leverage your expertise in implementing for your clients a solution that fits their desires with a minimum cost and time investment.
If they want to build and sell an OR/M. The go to town making one. If they want anything else, use one that already exists to get the job done.
If they insist on spending money, buy an existing one (I won't name any, but there exist some good ones that are not free).

Try to use Devart LinqConnect - all of the LINQ to SQL features and wide support of the most popular database servers - Oracle, MySQL, Postgre, SQL Server, and SQLite. Incredible Visual Modeling tool, advanced monitoring tool, high quality support - as a result i've learned it only in three weeks during my project execution.