I found this tool Visual NHibernate at http://www.slyce.com/, but a search on here has not brought anything up for what I would have thought would have been a very popular product, in concept anyway.
Has anyone used this product? Any feedback on it?
Thanks
Right, first let me say you are on the right track. Visual NHibernate has come a long way from a tool to generate NHibernate Mappings and Classes from just Microsoft SQL Server to a tool that does all the major Databases (I am biased cause it does MySQL now).
Like the name suggests, it doe the configuration setup visually with a rather tasteful (lately) UI (Probably WPF) that surprisingly does not tax your computer!! It also allows for setup of validation rules, Auto-detection of relational integrity (Primary - Foreign Keys) and all this with a very very flat learning curve.
If you use Oracle, Microsoft SQL Server or MySQL Server and you do not wish to spend too much time designing mappings and typing classes then this is the tool for you.
Related
Is it any better? I heard the CodeFirst extension but is it ready for primetime. Please share your experience with development, any performance overheads, etc.
I think this is a timely question, as I was wondering the exact same thing. I am trying to create a serious e-commerce model and I am trying to keep my POCOs free of persistence concerns as well as trying to stay true to Domain Driven Design. So far, I am very wary, and I am on the fence about whether I should jump ship to NHibernate. The only thing keeping me from doing so is that I assume that Microsoft will improve (and quickly).
Some of the biggest problems so far:
Inability to finely control object materialization. EF calls the zero-arg constructor on your POCO, and this is a behavior you cannot change.
No enum support. The community has been screaming -- screaming! -- for this, and it hasn't happened. The workarounds are terrible, and pollute your domain model.
Weird mapping bugs when trying to control column names and relationships in the database. The main ones I can think of are with compound keys and many-to-many relationships. These can be worked around, and I assume these will be fixed by release time, but they are frustrating nonetheless.
Bad SQL. I also do DBA work, and the SQL that EF generates (with or without Code-First) is atrocious.
And this is just the tip of the iceberg: I am only starting to learn EF4 and I'm running into awful roadblocks. As I think of more reasons, I'll add them here. I'm still struggling through it.
(I wonder whether the community will give it another vote of "no confidence.")
More:
To add to the "Weird mapping bugs" problem: You cannot control the name of a column if it participates in a self-referencing relationship (for example, if you have a hierarchy). I assume this will be fixed in the final release.
Lack of batching, resulting in multiple roundtrips to the database. For example, how do you delete a bunch of items from a collection? Load all entities into memory and delete them one at a time. A smaller gripe is the number of DB hits when inserting into tables that participate in an inheritance relationship.
No intelligent way to deal with model changes. EF Code-First loves to completely drop your entire database if it needs to change the schema.
Few extensibility points. You can literally count on one hand the number of events that EF4 allows you to subscribe to (and Code-First doesn't provide much more).
As for me - I prefer EF but with some enhancements. Basically EF offers to you the following advantages:
Visual Model Editor
Database/Model Update wizard (instead of manual XML changes - what is terrible for me)
Also, I'm using 3-rd party commercial tools based on EF and L2S (LinqConnect) that provide for me the following features:
Geography support
Optimized SQL generation
Product absolutely integrated to Visual Studio
Smart database update wizard (synchronization mode)
The dev tools for SQL in Visual Studio are great.
Is it possible to develop an app for Microsoft SQL Server, and then deploy a MySQL-compatible database instead?
The dev tools for Microsoft SQL Server are really nice (i.e. LINQ support), but a MySQL-compatible column database has better performance for huge datasets.
You would need to use MySql .net connector
http://dev.mysql.com/doc/refman/5.1/en/connector-net.html
With this, you get some of the functionality that you have with SQL server (entity framework, designer, etc) there are still a bunch of things that are not supported, but it's a good start
It's possible, but a number of specifics might tend to prevent a full implementation on SQL Server, particularly with respect to stored procedures.
However, if the intent is to build a scaffolding on VisStudio and finish the development using the MySQL tools, it would work okay. You'll have to learn both SQLs quite thoroughly. The sooner you do that, the less grief there will be in the conversion.
One method for doing this would be to abstract away the database itself. That be done at least a couple of ways; the first way, you could use classes to build the SQL that your application requires, and then just use that; then all that has to happen is that it has to know how to generate the right SQL for the right server. One of the drawbacks of doing it that way, though, is that if you depend on functionality that exists on only one DBMS, you'll have to emulate it in that abstraction layer.
The other method that you could use is to create two versions of your classes that talk to the RDBMS, one for MySQL and one for Microsoft's SQL Server. Use an interface and derive from it in order to do the actual implementation. Of course, you'll want to make sure that the only responsibility of the class is to interact with the database, so if you're doing this for business layer objects, you'll be implementing those sorts of things with two classes: a low-level one for the database API, and a high-level one for actually providing the API that your application is going to consume.
Perhaps not a direct answer to your question, but the dblinq project may be of use to you.
It may be worth a look just to see the MySQL implementations within the project in order to determine what the real differences between SQL Server and MySQL are going to be and how they're going to affect you. The more you can abstract out those differences behind a dependency implementation, the easier it'll be to swap out one implementation for another.
You can write your code for SQL Server and then switch to Devart LinqConnect.
For example, you can create a LINQ to SQL model using Entity Developer (in VS integration mode or in standalone mode), then change the connection to the MySQL-specific one and run Update Database from Model wizard (don't forget to select the Regenerate Storage check box).
As a result, you will obtain a MySQL database, having structure identical to the SQL Server one.
I have an object model that I want to store using an embedded database. I have so far been looking at db4o, NHibernate to SQLCE (w/ linq), and RavenDB. This would be used in a desktop C# application.
The key features I am looking to leverage are: Linq or similar for queries (no SQL or HQL), Embedded data engine, pocos, poco first model, no install (no registry or similar)
Can any one suggest one? Are the three I am looking at the best choices? Are there other options? Of the three, can anyone recommend one over the other?
Thanks
Well the three suggested databases are very different in their nature. SQLCE with Hibernate as RDBMS with a ORM, db4o as object database and RavenDB as document database. Each of them has its strengths.
SQL CE & NHibernate-Combo
The good:
Extremely good support in tooling, the knowledge and a big community is there
Easy to upgrage to MS SQL servers
Extrem good reporting support
The power of SQL
The bad:
Needs mapping
The mapping between the OO and relational world is not easy and can lead to issues with complex models.
RavenDB
The good:
Doesn't need any mapping
Easy to use
Powerful indexing
JSON & HTTP access
The bad:
If your domain doesn't fit to a document-oriented approach, it will be quite painful
It does not support the .NET Framework Client Profile (which is of particular importance as the OP's question is concerning embedded databases)
db4o
The good:
Doesn't need any mapping
Easy to use
The storage model is close the object-model. This also works for very complex models.
-
The bad:
Tooling support is weak.
Afaik all three support LINQ and POCO-first approach. However since NHibernate & SQL CE still need tons of mapping its not as friction free as it could be.
I think if your focus is on POCO first, LINQ-support, ebedded usage and easy to use, I would try RaveDB or db4o.
If your focus is on 'safety', community-knowledge, tool-support and reporting I would go with NHibernate and SQL CE.
Firebird is a terrific embedded database which has long supported all the modern features of an enterprise database:
ANSI SQL
ACID
Stored procedures
Triggers
You can get the .NET provider (last updated May 24th according to the site) and it supports Entity Framework and Linq.
See this question. For LINQ support, check out DbLinq, or since you already intend to use NHibernate you can use NHibernate's own LINQ provider.
I'm new to SQL and could use some help in creating a database schema for my program, which manages and installs programs for my home network. Are there any guidelines/tutorials for creating database schemas?
Probably the most important concept to understand before you design your schema (you'll thank yourself for it later, trust me! :-) is that of Normalisation. The tutorial at db.grussell.org doesn't look too shabby and will give you a good grounding. In fact, if you click the "Up One Level" link and take a look around, some of the other information might be quite useful as well.
My "top tip" is: Write it down on paper or in notepad, or anything other than a database, before you start writing code. Get a good idea of what you need your schema to be able to do before you set it in stone (And by "set it in stone" I mean, realise that you've written a load of code against the schema that would have to be re-written if you change it to do what you've just realised you now need).
Designing Databases is a separate field of study and expertise. It cannot be condensed into one answer. Since you are interested in tutorials, look at the section on Database Design in any text book on Database Management Systems. I would recommend
Database System Concepts, 5e, Abraham Silberschatz, Henry F.Korth, Sudarshan
In database design, remember the following
1) You are identifying the important objects of interest in your home network. Try to avoid excessive indulgence in the processes themselves though they are important to identify the important data units that you need to capture
2) Use ER/UML modelling techniques to come up with a Data Model Diagram/design. There are many case tools that can help you in drawing this.
3) Use the principles of Database Normalization to fine tune your schema to avoid data redundancies. Redundant data leads to the following side effects: Inability to maintain consistency among redundant data, Inability to store some data in an elegant manner
3) Forward engineer your design to DDL statements for the DB of your choice. Most case tools support this.
Case tools:
Microsoft Visio
ER Studio (very expensive)
TOAD data modeller
There are many open source tools too. You can try Dia. This does not support forward engineering
So I'm having a head against the wall moment and hoping somebody can come help either remove the wall or stop my head from moving!!
Over the last 3/4 weeks I've been investigating ORM's in readyness for a new project. The ORM must map to an existing, large and ageing SQL database.
So I tried Subsonic. I really liked v2 and v3 after modding to work nicely with VB and named schemas in SQL was running OK. However, its lack of flexibility of having separate entity properties names vs column names had me pulling my hair out (sorry Rob).
I tried Entity Framework but I found like others it lacking in certain areas.
So I bit the bullet and tried nHibernate but after a week or so getting it working how I liked (with help from Codesmith to generate classes/hbms for me) I'm frustrated with the time it takes to startup (build a config object), despite trying a number of tricks to reduce this time.
I'm essentially after building a DAL class that I can share between apps and websites. Am I barking up the wrong tree? For a legacy project with 100s of tables should I go back to ado.net and use DTOs? Aarrgh!
Sorry for the ranty style of question. I don't have much hair left and I'd like to keep what I have!!
Thanks in advance, Ed
PS. I should add that I know SQL very well and not scared of getting my hands dirty to write fast queries. If anything I don't need to be hid from SQL
ORM let's you:
To map table rows to objects, that are the the workable pieces of object oriented programming.
To automatically navigate through object relationships
To easily add, edit and remove table rows
To query the database in a more intuitive way as you don't have to think of joins (this one will depend on the ORM and the query method)
To transparently handle L1 and L2 cache.
All of the above would have to be handled by hand if you werent using ORM.
PS: I agree to Dmitry as to the startup time of NHibernate (see question comments). Besides, did you try Fluent NHibernate? Fluent NHibernate is impressively easy. I couldn't believe my eyes when I first mapped a database. It's even easier than proprietary ORMs like DevExpress XPO.
The biggest benefit of an ORM tool is that it will help you layer your application correctly. Most project nowadays use a Data Layer to connect to the database. You start from the ORM tool to produce classes that correspond to your database objects. Then you define an interface using these methods. All persistence code uses the methods of this interface. This way the business logic layer is only coupled to this higher-layer interface and needs to know nothing about the database. In fact there should be no dependency on ADO.NET or even NHibernate.
Another advantage of ORM tools is that you de-couple your application from the database server. You could change the db engine and still use the same code. Also there isn't only the complexity of the SQL that the ORM hides from you. It can also help you with transactions logic and connection pooling.
I'd say that for new projects an ORM tool is a necessity. For legacy projects it isn't so much beneficial, unless of course you have the time/money to start from scratch.
In my experience, most ORMs end up being way more complex than SQL. Which defeats the entire purpose of using them.
One solution I'm enthusiastic about is LINQ2SQL. It excels as a thin layer about stored procedures or views. It's really easy to use and doesn't try to hide SQL.
There are basically two questions here:
What's great about ORMs? There are similar questions on Stackoverflow. See:
What are the advantages of using an ORM?
Is everyone here jumping on the ORM band wagon?
How can I improve NHibernate startup time? See:
http://ayende.com/Blog/archive/2007/10/26/Real-World-NHibernate-Reducing-startup-times-for-large-amount-of.aspx
http://nhforge.org/blogs/nhibernate/archive/2009/03/13/an-improvement-on-sessionfactory-initialization.aspx