I'm just getting underway with Orchard CMS. How difficult would it be to create an Orchard module that uses RavenDB as its database? Is a hard dependency on SQL and NHibernate baked deeply into Orchard?
All of Orchard's core features are based on NHibernate so it would be difficult to move the entire Orchard database to another DBMS not supported by NHibernate. However, Orchard is very extensible and it is quite easy to access all kinds of custom data sources from your own modules. For example, I am currently working in a project where we store our data in a graph database (neo4j) and access them in Orchard using a WCF service.
It depends on what kind of data you need to access, but you will probably need to create a custom content part which dynamically loads data instead of using the underlying SQL database through NHibernate. You can do this by inheriting from the non-generic ContentPart class (the generic one uses a record stored using NHibernate) and using a ContentHandler to populate the data from your custom data source.
There is an experimental RavenDB-based data layer implementation in 'ravendb' Mercurial branch.
It was built a couple of months ago and I'm not sure about the compatibility with the current release, but you can give it a try. There were no big changes to DL since then so I assume it should work or need just a couple of tweaks.
Related
I have legacy code that has DB connected.I'm trying to add new features for this app with Symfony2. I used Theodo Evolution Bundle to access the legacy session.
First thing that I want to do now, is to build an API that will use data from existing database. This database has tables that are not converted to entities. My question is which is best approach in this case. To use native queries from existing tables in database to build API or to convert tables into entities I used documentation for this part but I'm not sure will import all relations and everything) and then to build API. Can you please suggest me which is best approach in this case. Thank you.
The best approach in my opinion is to work with doctrine entities within the framework and to avoid direct SQL if possible. That is the basic philosophy behind frameworks such as Symfony: the database layer should be abstracted.
The entity-database mapping might be quite more of a hassle at first, because you can't rely on automatic tools to set it up, but once it's done it will be much easier to work out the rest of the application.
Today I was checking out a few technologies: T4 templating, automapper
some mini orms: petapoco, sqlfu, ormlite
I understand the gist of what these technologies provide. I'm currently working on a 3 tier system, and I would have loved to replace the DAL (data access layer located on it's own data server) and have it integrated with a mini ORM as shown. However, I will be making no such plans for now. We currently use .NET Remoting (predates WCF).
So instead of replacing whatever is on the DataServer, I'd like to extend one of these new technologies on the application server.
I've done research on how Entity Framework can automatically generate POCO classes based on the context, which is done manually after building EF, I was wondering if I can do the same without using EF.
So here's the facts on what's currently happening:
Send a sql statement (or stored proc) to the DAL to execute
Retrieves a DataSet or a DataTable back to the application through TCP channel
My question is, is it possible to automatically generate a dynamic POCO class using keywords "var" and "dynamic" based on the values sent back from the DataSet and do dynamic mapping onto it during runtime? Would any of the technologies mentioned above help? Or do I have to manually create the POCO class first, and do a mapping on it?
It seems a bit redundant for me to manually create a POCO class and map it to a backend sql table if the application could be aware of what the POCO class is supposed to have. Like what happens if I update a table on the backend, then I'd have to update the POCO class associated with it as well. I'd love to have this to be automatic for me.
If you know the data sets at compile time, then T4 might be an option. You can write a T4 script that downloads the database schema, and constructs strongly-typed entity classes and database reads/write methods.
As far late-bound (runtime) classes, one option is to use the runtime typing provided by CustomTypeDescriptor. You can pass arrays of objects back and forth from the server, and use reflection or other techniques to infer the type.
I think it should be clear that #1 is preferable, if you know the types at compile time (which it sounds like in your case here). Runtime and dynamic should only be a last resort, as it circumvents a lot of valuable compile-time type checks.
Really, I would recommend using one of the micro ORMs like Dapper, etc, if you don't want to use the full Entity Framework. That is, unless you really want to re-invent the wheel.
I'm putting a front-end together for one of our databases and would like to use NHibernate for it.
Can anyone point out any resources for getting started with Database-first approach? Most tutorials I've seen are for Code/Entity First.
ASP.NET MVC 3 will be my environment, if it matters.
Thanks.
It is all about configuring with NHibernate. As long as Nhibernate is concern, it will not create a database if that is not exists. So you have to configure Nhibernate with the connection string of your existing database in hibernate.cfg.xml(You can also use loquacious api)
There are lots of configuration possibility in NHibernate; Example includes ConfORM, FluentNhibernate, Configuring With Code, XML.
For existing database going with xml is often easy. If you choose xml, you can use tools like myGeneration to generate mappings for you.
As long as you map your object correctly with the existing database nibernate will not complain whether you create your database first or code first. So any intorductory example/application/resource that uses nhibernate as an orm mapper should serve as getting started for you.
Still there are some techniques you can follow to do database first modeling. Here is a link that may help(code example) Effective Techniques for Database-Driven Modeling
Here is the Screen Cast Explaining the techniques
please take a look at this: http://www.devart.com/entitydeveloper/nhibernate-designer.html it is not a freeware.
There is another open source tool which was referred in another question long time back. here is the link: http://www.mygenerationsoftware.com/phpBB2/viewtopic.php?t=1505
btw are you planning to use fluent nhibenrate or just nhibernate?
On a side note: Entity Framework supports a database-first approach with an integrated designer for Visual Studio. This designer produces an XML file (EDMX) that describes the required mappings.
Note: I am not marketing any of these products.
I'm thinking of adopting a more Domain-Driven-Design approach to DotNetNuke module development and would like to consider using NHibernate as an OR/M layer.
Does anyone have experience using NHibernate with DotNetNuke? I've used SubSonic and EntitySpaces, but not NH.
UPDATE
Sorry, I should have been more clear. Is NHibernate capable of running in Medium Trust and able to run in the context of the DotNetNuke "objectqualifier" ? The DNN object qualifier is essentially a prefix that can be applied to all database table names. So on my DNN install I might have a table named "Products", but on someone else's the same table might be named "dnn_Products" where the "dnn" is the "objectqualifier". So essentially NHibernate would need to read the objectqualifier from the web.config at runtime and apply it.
NHibernate can be used with essentially any table name. When you define the table mapping in your mapping xml you need to simply define the table name as dnn_Products. As long as that is the actual name of the table then it will work. NHibernate is capable of running in Medium Trust, the trick is getting the NHibernate dll's into your DNN install. You can add them in an Assembly Component from what I understand but I have never had the need to validate that personally.
You can see this example.
The article is not for the same topic you are looking but it will give you good idea about it.
How do you create a database from an Entity Data Model.
So I created a database using the EDM Designer in VisualStudio 2008, and now I want to generate the SQL Server Schema to create storage in SQL Server.
From what I understand you are not just supposed to use EDM as a "pretty" database designer, in fact EDM does not depend on a specific storage layer. It tries to abstract that part for the developer. There are design schemas (CSDL) and storage schemas (SSDL). Anyway, don't mean to lecture you. ;)
There is EDM Generator, which you use to create models and class, etc.. For a DDL kind of export, I've never done that but what I did was map my EDM to an existing database, which was easier for me to get started.
There is a great tutorial on MSDN, which details step by step instructions on how to go about using an existing database, but also touches the how to start from scratch approach.
http://msdn.microsoft.com/en-us/magazine/cc163286.aspx
The Feature "Generate Database Schema from Model" is scheduled for a future release of Entity Framework. V1 does'nt support schema generatiorn based on EF models.
I believe the other answers implied this, but just to be explicit - use SSMS (or whatever equivlent if you're a brave sole and not using SQL Server provider) to design the DB layout and then suck that into EDM - and then apply application changes as necessary to the model.
I spent about an hour trying to do it your way first (leftover habit from some other Java ORM tools) - I eventually gave up and now do it the 'Right Way' (tm)
Eventually it would be nice (as JRoppert indicated) to have the generate databse schema from model feature - then you could get your DDLs for various DB flavours automagically.
Generating databases from model is a feature planned for vNext of Entity Framework.
Check out this blog post of Entity Framework Design explaining the planned features for database generation from a model.
What you must do right now is either 1) generate the database by hand, or 2) parse the CSDL file and write your own generator. I think option 1) is probably a better option.
Avilable in EF 4:
http://blogs.msdn.com/b/efdesign/archive/2008/09/10/model-first.aspx