I have a database. I have a Wcf Service project which is connected to the database and has a data model (.edmx file).
Now I need to add an Asp.Net MVC application.
The tutorials I'm reading say that I should only add the connectionString. But, does that mean that I don't need model classes? Or should I create model classes? Also, the classes in the .edmx file don't extend from DbContext the class.
For example, I have a table named Something in my database which doesn't extend from DbContext.
Do I add a model named SomethingTemplate with all the properties from Something and make it extend from DbContext?
In a properly designed ASP.NET MVC application the data access layer is abstracted. This means that no matter whether you are using plain ADO.NET, EF, NHibernate or even remote WCF service calls it doesn't really matter.
In the case of WCF if you want to use EF, you will define your data contexts and entities inside this project. The connection string will also be inside the WCF project.
Then in your ASP.NET MVC application you will simply add a service reference to this WCF service which will create a client side proxy allowing you to invoke its methods. It will also import the entities but from the ASP.NET MVC perspective they will be POCOs.
Related
Let's say I am developing a few ASP.NET MVC applications working with data in an existing database just over by stored procedures, no and never linq to entities or anything else. That database contains lots of schemas and all my web applications needs the different schemas as well.
Here is my point:
I have a x.Model project in my solution that contains my ADO.NET Entity Model to create return types for all of my stored procedures in my existing db.
I have x.Repository.y projects in my solution where y is the schema name in the database. These projects contains classes having functions to call the stored procedures from the appropriate schema by ADO.NET Entity Model's context. So I have to have reference of x.Model in these repository projects.
And I have ASP.NET MVC projects that uses the necessary injected repositories from x.Repository.y projects. I use some of these return types of stored procedures as models in my views, so I need a reference to x.Model project too. But in that case this reference gives all the context to client web applications. I don't want my whole or partial db entities is reachable in my web applications. I just want them to know about necessary repository classes.
Is it possible? How can I do that?
If I remove x.Model project and create the ADO.NET Entity Models containing just the appropriate schemas stored procedures in my x.Repository.y projects then the referencing web applications again knows about this schema's whole db entities.
Thanks in advance,
Maybe, better way to use Model First or Code First approach. So, you can describe pure (without references to DbContext and other Data classes) entities. Then, create mapping in x.Repository project. And referene your Model to ASP.NET MVC site. So, you will have only entities and repositories but mapping and DbContext will be hidden inside one reference (you can mark mapping classes as internal).
I am building a web application which will have a public facing piece with a forms login, and an internal piece with windows authentication login. The two projects will be using the same database. I would like to rely on Visual Studio tooling as much as possible, but do things the right way.
I was thinking of creating three projects in a single solution:
Internal - ASP.Net MVC 4 Intranet application
External - ASP.Net MVC 4 Internet application
Models - just a class library
What is the best way to handle membership and database context? Move everything to the models class?
For your database access, you may be best placed to put all that configuration and your POCO classes (classes that represent your database tables) inside a Data project.
You could then put your Business logic and any other utilities inside a Core layer, this is what your Web will use to talk to the database (Core references Data).
Now, the structure of the Web side should probably just be one MVC project, you could separate both the Intranet and Extranet/External to be different Areas in that project.
To summarise:
YourApp.Data - Contains Database Configuration, POCO classes that correspond to Database tables. Also contains database CRUD methods.
YourApp.Core - References Data, wraps calls to the CRUD methods in Data inside appropriate Business Logic/Validation/Exception Handling etc.
YourApp.Web - References Core, makes call to Core methods to perform CRUD operations. Contains two Areas -> External and Intranet for each parts of your application.
I\m using WebAPI in ASP.net MVC 4.5, and I was wondering what is the best practice when dealing the db entities, should I create another Model (you can call it API model or Service model) that deals with the API, pretty much the same way you create a View model to deal with the razor view, or just communicate directly with the db using the EF entities.
When it's a public API, I think its better to create extra Web API entities (Models in MVC). You can write a method to map the db entities to Web API entities. When you create extra entities your sure the public side of your API doesn't change when you change database entities.
How would I go about abstracting the membership information in MVC3 c#
Currently the membership data is kept on a localhost SQL server and is linked to MVC via the Entity Framework.
As I want to perform some extensions, I need to abstract it, creating an interface and class for each entity in the SQL database?
Where would I start? Are there any examples available? I can only find ones that are out of date or irrelevant
I think you can rearrange your application, introducing a service layer separated from your presentation layer. The object model (domain model) that you define in the presentation layer for User and other entities should be distinct from the EF data model, so you need only that some sevices ( for example you can implement these as Web Services) read the data using EF and populate your domain model of the presentataion layer.
This approach allows your application to be more flexible to future changes or extensions.
So I have a DataEntity class generated by EntityFramework4 for my sqlexpress08 database. This data context is exposed via a WCF Data Service/Odata to silverlight and win forms clients.
Should the data entities + edmx file (generated by EF4) go in a separate class library?
The problem here then is I would specify data annotations for a few entities and then some of them would require specific MVC attributes (like CompareAttribute) so the class library would also reference mvc dlls. There also happen to be entity users which will be encapsulated or wrapped into an IIdentity in the website. So its pretty tied to the mvc website. Or Should it maybe go in a Base folder in the mvc project itself?
Mostly the website is data driven around the database, like approve users, change global settings etc. The real business happens in the silverlight and win forms apps.
Im using mvc3 rc2 with Razor.
Thanks
Should the data entities + edmx file (generated by EF4) go in a separate class library?
IMHO all data access logic which is specific to some data access technology (in your case Entity Framework) should go into a separate assembly. There should be no MVC specific assemblies referenced there.
In your ASP.NET MVC application you would then reference this assembly and write view models. It is those view models that will contain any MVC specific attributes. Then you could map between your model classes and those view models which would be passed to the view. AutoMapper could be used to facilitate this task.