We are working on suite of applications in our company. Each applications have different business logic but share some structures. For example one application is for "IT services" and another one is for "package handling system" among different buildings of the company. We want to create each application with separate asp.net mvc projects (Entity framework Code-First). But the problem is that all of the applications have some similar entities. For example all of them have People, Buildings and Floors Entities in their dbContext. and also have some other tables that have relations to this similar tables
What is the best approach to designing this applications?
Create a single database for all of the applications? what is side-effects?
Create separate Database for each application and duplicate the similar Tables? (currently we working on this but we should write some SQL server jobs to always sync this tables. so I don't think its a good approach)
Create a database for shared tables and another databases for each application. This will cause to lose relations between tables and also produces multi-Context applications (I prefer this but I read that with Code-First EF and linq, it is not possible to query cross multiple contexts)
or something else ?
I am very interesting for Db management system. I like your 3 aproach firstly. All of them different advantages and disadvantages. If you have huge datas on this db may you can use seperate Database like solution like 2. But you have to develop sync mechanism that you said. If we look at another advantge of seperate db that when one db is failed or broken, another db can work :) but some of departmant data can be unavaible until error fixed. This can be good for huge systems.
Lastyly, "Create a database for shared tables and another databases for each application ", this idea is so good :)
May you can use N-Tier artitecture at least 3 tier(Business-Presentation-Data)and
Busines==> Your Worker Functions
Data Layer==> Many Db Context
Presentation ==> MVC project
I think the solution 3 and Lose Coupling Connection with N-Tier Artch is best way.
Lastly may you seach;
Unit Of work, Ninject Freamwork, N-Tier topics
Note: Alwasy the code-first :) I like Code First style to much :D
Have a nice day :)
If you want I can show a few N-Tier structure Lesson Link around "CodeProject.com" and Stackoverflow
Related
I have used MVC thus far in a traditional EF sense by creating POCO first objects and then adding this to a database context but I have a new problem in that I am trying to recreate a legacy system but using the MVC framework but it uses a connection to multiple different databases and tables.
In the legacy solution they use Enterprise library to create the link to databases but I am not sure that this is the best option available and was wondering what are the options open for dbconext in regards to different database connections at the same time, is this possible?
The question is nothing to do with MVC. Besides, ASP.Net MVC (Presentation Layer) should not even need to know about what kind of ORM or database at Data Access Layer.
Back to original question, it is not worth using Entity Framework, if you have to query two databases at the same time.
I suggest you want to look at other ORM like Dapper.
I have one project，need build more then 300 models, i want use EF codefirst.
But I think saved in one database Seems not so good.
so I want to know how to Save more then 300models to 5 database and use code first?
Do it right?
How to do it?
Have the mature example ?
how to query data by Navigate properties in tow models? They are not in same database，
I want query by lambda int these database like One database (on DbContext).
I am chinase .so English is very Bad.
I hope you can understand what I'm saying
The problem with splitting the models across multiple databases is that you cannot have foreign key relationships between the two databases.
If you are using multiple databases you will need to handle all the navigation yourself in code.
You should consider redesigning the database so that there are less base models and then using application level models to access the required models.
Another option is to use ubermodels keeping all 300 tables and then use application level models. This can be aided by techniques proposed in the article here on shrinking EF models that may help.
On one server there are more than 20 databases with identical structure but different data. I need to collect some of the data (the same queries) from all databases and store in new database which is located on another server. I decided to use ASP.NET MVC 2 but it doesn't seem logical to use more than 20 "LINQ to SQL Classes" (.dbml) files because the structure is the same for all databases and it's repeating if I use so many of these files. Is there a simple way to use one .dbml file (for remote databases) but change only connection string?
I agree that you really wouldn't want to use MVC as that is a web framework and has nothing to do with moving data around.
You can also look into using an ETL tool to accomplish this task. I have used RhinoETL in the past successfully to accomplish something similar.
There are also multiple posts on this site discussing ETL tools. For example, check the following link - https://stackoverflow.com/questions/51198/what-etl-tool-do-you-use
According to this, you can pass in a connection string with the dataContext constructor. So theoretically, you should be able to have one dbml file, but you can instantiate multiple instances of your data context, each with a different database connection string specified. Each context should then point to their respective database and allow you to work with multiple databases.
Why do you want to use ASP.NET MVC at all? ASP.NET is for web UI, not data warehousing (except when you need to display cubes). Looks like you use SQL Server. If that is true you can utilize Integration Services (ex DTS) to do the job.
I was wondering if EF4 support cross-databse relationships? For instance:
db1
Author
Id
Name
db2
Posts
Id
Content
db1.Author.Id
What ideally I need to do to get this relation in my ef4 model?
Do you guys have any idea?
Thanks
I've found this entry in Microsoft Connect that answers the question about the support given at this moment by EF (actually it is not supported yet).
Also found a thread in Social MSDN about this concern.
Other links on Stack Overflow:
ADO.Net Entity Framework across multiple databases
Entity framework 4 and multiple database
In summary, the only given alternatives are:
Using views in EF
Use NHibernate instead
If your database supports Synonyms, you can trick EF to span multiple databases. I wrote up how to do it here.
Basically you end up with an edmx file per database, and a script which merges them into a single edmx file. Synonyms are used to reference one database from another by using the actual table name, so EF doesn't throw a fit when you try to access database2.table from database1. You still have to setup links between the two databases manually in the EF model, but once setup they'll stay even if you re-run the merge script.
Scripts to setup Synonyms and to merge the edmx files are posted in the link
I recently began a project that uses entity framework with two databases, one Oracle and one SQL Server. I could not find any information regarding cross-database or multiple database support in the entity framework.
Most posts from the MS Entity framework team are a couple of years old and indicate that including two databases in a single model is not a feature that will be included soon. I would be interested in having a concrete answer on whether it was included in 2010 myself although I suspect the answer is no.
Currently out project gets around this limitation by having a separate entity model for each database. This has solved the problem for the majority of the scenarios we've encountered thus far in the project.
In cases where we've needed to query the data from the two databases at the same time, we simply created a view in one or the other databases. Since we're using Oracle and SQL Server, this view would utilize either a Linked Server (SQL) or a DBLink (Oracle).
The disadvantage of views in the entity framework is we've had to spent more time than I expected getting the primary keys working.
Hope this helps.
We're about to embark on some ASP.NET MVC development and have been using our own entity framework for years. However we need to support more than our entity framework is capable of and so I'd like to get some opinions about using MVC with a more robust framework. We have narrowed down or choices to either NHibernate (with the Fluent APIs) or LINQ to SQL.
Which framework lends itself best to MVC style development (I know SO uses LINQ to SQL)?
If we want to support SQL Server, Oracle, MySQL - does that exclude LINQ to SQL?
As someone who has just switched from LINQ to SQL to (Fluent) NHibernate, here are a few things I've noticed.
LINQ to SQL took so long to figure out how to do the equivalent of a join-subclass. After many modifications, I read somewhere that it is not possible. It can only map inheritance if ALL the columns are in that same table. This is great if there are a few columns, but there are tons in my case and sub classes are parents to other sub classes and so on. Why should I put them all in one table for the sake of my ORM?
NHibernate from experience has been robust (sometimes too much for small quick projects) and although familiar with it through small projects, I felt it might be too much and went the route of LINQ to SQL since I could generate a DBML file and be going within minutes.
Fluent NHibernate. Takes the best of both worlds (in my case). I can map the way I want to and have my database the way I want and not have to compromise in my domain or data models. Also one word: Automapping... icing on the cake.
I would have had to go with another ORM once I found limitations and hit a few road bumps with LINQ to SQL, but Fluent NHibernate made this choice easy, and I don't think I'll leave it unless something comes around that does the job even better.
So, like Rob Scott said, the question is how are you abstracting you domain => data model? And are you starting with a domain or a database? How complex are the relationships? If you have any inheritance at all I'd say just go with a richer ORM framework and save yourself the grief.
Fluent NHibernate has some of the best documentation I've ever found and there are so much support, notes, blogs and resources it's self-hate to do anything less... IMO! I was up and running in less than 24 hours.
Oh and if your'e new to NHibernate pick up the NHibernate in Action book to help grease the wheels although there is a lot of help for that framework as well.
The best indication that a tool isn't working is when you have to WORK the tool... LINQ to SQL I was customizing, reading white papers, all sorts of madness and it refused to generate appropriate queries, right when I was tempted to modify my table and domain, I said let me give Fluent a whirl, and I'm happy I did.
Good luck to you.. Sorry for the long response; this has all been in the past five or so days, so I guess I'm still caught up :-)
I've had great success using Fluent NHibernate and dependency injection (Ninject, in my case) with MVC.
It seems to me though that any mature ORM should work well with MVC. Since the nature of MVC (Model/View/Controller) separates the three concerns, any ORM should fit quite nicely into the "Model" role.
LINQ to SQL is for SQL Server. Entity Framework supports some other databases as well.
NHibernate is good choice. You may use Castle ActiveRecord (it's built on top of NH) if you are doing data based application or Sharp Architecture for project guidance.
Entity Framework integrates nicely with MVC and supports other databases.
The short (and not so helpful) answer is that both of the ORMs you've mentioned will work with MVC. A longer answer is that you should think about how you want to work with your model objects. For example, do you want to do domain object first development (ala a Domain Driven Design approach), or are you implementing a "forms over data" type application where you might want to generate a data access layer from an existing db? What is your preference for specifying mappings? Do you want to use a fluent interface or are you happy with mapping files (or attributes on your domain objects)?
These are the type of questions you need to investigate when choosing an ORM -- and they're mostly independent of whether you're using MVC or Winforms.
Entity Framework makes things complex. Use Fluent NHibernate, with Repository pattern and inversion of control in controllers.
NHibernate will make lots of things easier. We have recently migrated from Entity Framework to Fluent Nhibernate, and Fluent NHibernate is definitely the better candidate.