I've recently started to play around with ASP.net MVC3 and the Entity Framework. I followed tutorials (code, model and database first) and I liked alot of the automagical things happening.
BUT (always a but...), it seem to me that the whole "system" is very much constructed for someone hosting the whole thing by themselves with total control. I'm trying to understand how it can be useful to me in my hobby projects and self learning and so far I've failed.
What I'm getting at is this: I have a pretty regular web hotel, I own a couple of domains there. But I only have 1 MS SQL database. And it seems which every way I go with code, model or database first my sites/projects/tests fight eachother in that database - dropping eachothers tables.
On the web hotel I have to use a package from NuGet so that only tables are being created on model change - no database dropping allowed. But tables that not exist in one sites project are being dropped and conflicts arrise.
Am I missing something or did they really not construct the framework for people like me?
If I had a MS SQL database dedicated for each site I want to work on it would work of course but since that is an extra service it will get very expensive. And my projects are very tiny at this pont so having them share a database is no problem performance-wise.
Can anyone advice me, say what point I'm missing or point me in the right direction?
Thanks in advance!
It sounds like you're using the code-first variety of EF. Try the database-first variety and generate your model from the database, rather than vice versa.
Related
I learned to love how LINQ enables set operations on collections. I'm not saying that I plan to shun traditional RDMBS, because I do need it for reporting. There are NoSQL alternatives out there, but they seem to all need to fire up a separate service.
What I looking for is something local where a DLL can create a database and perform CRUD on it. As mentioned, I'm not going to report out of this, just internal data store. The main application that will be using it is in C#.
I'm hoping that someone can give me a lead. If not, if there is anyone willing, we can start a open-source project for it. I'm not interested in commercial products.
Thanks,
You can run RavenDB in embedded mode inside your .NET application - no need for external services or anything.
And RavenDB supports Linq....
I've built a site in MVC3 using EF 4.0 using the Repository pattern. Everything was going good but I'm starting to run into a lot of "The relationship between the two objects cannot be defined because they are attached to different ObjectContext objects" errors. It seems that my repository layer is getting the contexts all mixed up, so I figured it might just be easier to start a new EF4.1 project.
At first I looked into Repository Pattern + Unit of Work, but came across some threads saying that this isn't needed for EF4.1. I came across this thread saying "DbContext is implementation of unit of work pattern and IDbSet is implementation of repository pattern.". I figured maybe then I could just use that. Upon further inspection though it seems that DbContext uses the Code First approach, which as far as I can tell will drop and create the database again if the POCOs change. I need to keep the data in my database, so as far as I can tell that option is out.
My head is spinning right now with EF options. Is the Repository pattern needed with EF4.1? Is DbContext meant for working on databases that are already full of data? Is there a better way of managing the entity contexts that don't involve these?
Any push in the right direction would be great =/
A few comments. For details I recommend to do some basic research using a search engine.
...I'm starting to run into a lot of "The relationship between the two
objects cannot be defined because they are attached to different
ObjectContext objects" errors. It seems that my repository layer is
getting the contexts all mixed up, so I figured it might just be
easier to start a new EF4.1 project.
If you have this error you did something wrong. EF 4.1 won't protect you to do the same mistake again because you also cannot change relationships between objects that are attached to different DbContexts. You just have to analyze and debug your code and find the source of the problem.
...this thread saying "DbContext is implementation of unit of work
pattern and IDbSet is implementation of repository pattern.". I
figured maybe then I could just use that...
ObjectContext and ObjectSet<T> is an implementation of those patterns as well. This is no reason to change the version of Entity Framework.
Upon further inspection though it seems that DbContext uses the Code
First approach...
You can also use Database First and Model First approach with DbContext.
...which as far as I can tell will drop and create the database again
if the POCOs change. I need to keep the data in my database, so as far
as I can tell that option is out.
You can turn that feature off. Also, EF 4.3 has a migration feature which helps to update and evolve an existing database schema.
Is the Repository pattern needed with EF4.1?
No. It's also not needed for ObjectContext. To be precise, it's not needed that you write your own (abstract) repository of top of EF, because EF is already an implementation of that pattern.
Is DbContext meant for working on databases that are already full of
data?
Yes. The additional feature to create a database from code (Code-First) is mainly a productivity tool for the development phase of your application which is supposed to be disabled in production.
I have a asp.net project and Its in designing phase. Its about products and shops navigation system. Users can browse/search products. I want my web application to be extendable and flexible. What I initially planned was to make it an MVC and for database I propose ORM (Object Relational Mapping). Is that right? what could be the problems I face with this proposal. I am learning asp.net so I don't know much about the problems.What design do you people suggest?
It's great that you've decided to learn ASP.NET.
Regarding design approach, it sounds like your question is 2 part: a) MVC or traditional web forms ASP.NET, and b) ORM or no ORM.
a) Generally speaking, if you have a good programming background, I would recommend MVC over web forms for any consumer facing Internet product. It promotes testability, clear separation of concerns, and gives the developer finer grained control over the UI.
b) Regarding ORM or no ORM - first, its important to note that you still need to choose a database. ORM is merely a means of abstracting the data access logic away from the developer - but there still needs to be a database to store the data. If you're going with an all Microsoft stack, you'll probably choose SQL Server.
ORM is great for developer productivity - and generally speaking, there's no reason not to choose it for new projects unless you can identify up front that its not going to provide a productivity boost. An example reason why you would choose not to adopt ORM - you need to persist the data in a pre-defined format - or in an already existing database - and the persisted entities are not consistent with how your application is representing them (i.e. over-normalized). In this case, you may want to write your own data access logic, and not rely on an ORM.
Finally, if all you are looking to accomplish is putting a product catalog online, rather than building an application from scratch to do this - you may want to consider utilizing an existing CMS of some sort, or even use Wordpress with some plugins. Would save hours of time and still accomplish your stated goal.
Best of luck!
If you want a really good reference on how to build application using MVC and ORM, then read the following book : Professional ASP.NET Design Patterns
It explains in details as how to build application using MVC. It also covers other interesting topics like dependency injection, repository pattern(very important expecially if you have decided to go for ORM), TDD etc. I hope you will enjoy reading this text.
MVC sets up clear distinction between Model, View and Controller.
For the model, now adays, web frameworks provides ability to map the model directly to database entities (ORM), which, IMHO, end up causing performance issues at runtime due to direct database I/O.
The thing is, if that's really the case, why model ORM is so pupular and every web frameworks want to support it either organically or not.
To a web site has huge amount of traffic, it definitely won't work. But what's the work around? Connect directly to database is definitely not a wise solution here.
What's your question?
Is it a good idea to use direct db access from webpages?
A: No.
Is it a good idea to use ORM's?
A: Debatable : See How can I design a Java web application without an ORM and without embedded SQL
Is it a good idea to use MVC model?
A: Yes - it has nothing to do with "Direct" database access - it's about separating your application logic from your model and your display. (Put simply).
And the rationale for not putting database logic inside webpages has nothing to do with performance - it's about security/maintainability etc etc. Calling a usp from a webpage is likely to be MORE performant than using an ORM, but it's bad because the performance gain is negligible, and the cons are significant.
As to workaround: if you mean how do you hook up a database to a web application...?
The simplest way is to use something like Entity Frameworks or Linq-Sql with your Model - there are plenty of examples of this in tutorials on the web.
A better method IMO, is to have a separate Services layer (which may be WCF based), and have all the database access inside that, with DTO's transferring the data to your Web Application which has it's own ViewModel.
Mvc is not about orm but about separation of display logics and business logics. There is no reason your exposed model needs to be identical to you database model and many reasons to ensure that the exposed model closely matches what is to be displayed.
The other part of the solution to scale well would be to implement caching in the control and be able to distribute load on sevaral instances.
I think #BonyT has given a good answer, (and I've voted for it :) ), I'd just add that:
"web frameworks provide the ability to map the model directly to database entities (ORM), which, IMHO, ends up causing performance issues at runtime due to direct database I/O"
Even if this is true, using an ORM can solve a lot of problems with a model being easy to update and translate back and forth between a database. Solving a performance hit by buying extra web servers or cloud instances is much cheaper than having to buy extra developers or extra hours in development to solve things other people have already written ORMs to do for you.
We are designing our new product, which will include multi-tenancy. It will be written in ASP.NET and C#, and may be hosted on Windows Azure or some other Cloud hosting solution.
We’ve been looking at MVC and other technologies and, to be honest, we’re getting bogged down in various acronyms (MVC, EF, WCF etc. etc.).
A particular requirement of our application is causing a headache – the users will be able to add fields to the database, or even create a whole new module.
As a result, each tenant would have a database with a different structure to every other tenant using the system. We envisage that every tenant will have their own database, rather than sharing a database.
(Adding fields etc. to the system will be accomplished using a web interface).
All well and good, but the problem comes when creating a data model for MVC. Modifying a data model programmatically to add a field to a table seems to be impossible, according to this link:
Create EDM during runtime?
This is a major headache for us. Even if we don’t use MVC, I think we’d still want to create a data model (perhaps for used with LINQ to SQL).
We’re considering having a table with loads of fields in it, and instead of adding fields to the database we allocate an existing field in the table when the user wants to add a field to his form. Not sure I like that idea, though.
Of course, we don’t have to use MVC or Entity Framework, but it appears to me that these are the kind of technologies that Microsoft would steer us towards for future development.
Any thoughts? I’m assuming that we’re not the first people in the world to consider this idea of a user-customisable application.
I'd make sure that you have fully explored the option of creating 'Name-Value Pair' type tables as described here http://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_nvp
before you start looking at a customizable schema. Also don't forget that you are going to have to grant much higher permissions to your sql accounts in order for them to create tables on the fly.
A customizable schema means that your sql accounts will also need much higher permissions. It wouldnt be advisable to assign these higher permissions to a tenants account, but to a separate provisioning account which can perform these tasks.
Also before investing effort into EF - try googling 'EF Vote of No Confidence'. It was raised (i believe) mainly in reaction to earlier versions but its definately worth reading up on. nHibernate is an alternative worth investigating.
Just off the top of my head it sounds like a bad idea to allow users to change the database schema. I think you are missing a layer of abstraction. In my mind, it would be more correct to use the database to hold data that describes the format of a customer's data. The actual data would then be saved in a text column as xml, including version information.
This solution may not fit your needs, but I don't know the details of your project. So just consider it my 5 cents.
Most modern SQL databases today supports the 'jsonb' type for key/value storage as a field. Other types (hstor for postgres) exists too. Forget about XML, that's yesterday and no application with respect for itself implements XML unless it is for importing/converting old data.