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).
Related
I've made an application in ASP.NET MVC. I first created an database in SQL Server and then installed the Entity Framework in Visual Studio and used the Entity Data Model Wizard, I selected the 'Code First from database', and it generated the derived DbContext Class and the models from the database.
My question is basically, why is it called 'Code First' when all the classes are generated based on the database - I've basically written no code, apart from the SQL.
Normally Code first refers to generating the database from your POCO but typically when you are targeting an existing database you can have the VS tools create the classes for you to get up and running quickly.
That is the impression I go from typing Code First from database into google.
Code-First from an Existing Database:
Entity Framework provides an easy way to use code-first approach for
an existing database. It will create entity classes for all the tables
& views in your existing database and configure it with
DataAnnotations attributes and Fluent API.
Additional source:
ScottGu's Blog - Using EF “Code First” with an Existing Database
EF “Code First” works great with existing databases, and enables a
very nice code-centric development approach with them. In particular,
it enables you to use clean “plain old classes” (aka POCO) for your
model objects, and cleanly map them to/from the database using either
the default mapping conventions or by overriding them with custom
schema mapping rules.
I'm Developing ASP.NET MVC Web Application project, and I'm using Entity Framework Database First Approach, So I would like to make validations on generated model classes, I know if i make validations on them directly, then my model validations will be overwritten every time my domain models are regenerated.
So I made a research, and found two approaches to use for this scenario:
1- Using buddy classes (How to add validation to my POCO(template) classes).
2- Using ViewModels and Auto-mapping them to my Entities (Designing an MVC repository using ViewModels
I see some sort of redundant code in these two methods, so, my question is:
Which one of the two approaches is best to flow?
1) This is the correct solution for adding validation metadata for the Entity Framework objects. The validation will be triggered automatically by EF before calling SaveChanges()
2) This is an aproach for creating Data Transfer Objects from your EF objects. You normally do this when you want to return the objects to the client (like in JSON format) - and you don't want to expose all the EF specific properties (like navigation properties, primary keys etc)
Say I have a Visual studio solution with two projects: one web project, and one data project.
Does it really matter whether I pass the EF object from the data project to the web project, or do I need to explicitly define POCOs in the data project to pass to the web project?
It seems to me that needing to create POCOs instead of simply using EF objects adds yet another thing that needs to be done...and I don't particularly see the purpose.
If you're using Entity Framework 4, the EF objects are POCO objects, and so should be used in any situation where your Model matches your EF object (CRUD operations are the typical ones). However there will more than likely be situations whereby the standard POCO object doesn't encapsulate all of the fields that are needed for a View Model (typical ones I have this with are account pages where you have two password fields) and so you will need to create a Model for the page, which then passes the data into your EF POCO objects.
So if you're using DbContext (which creates POCO objects for you) there is no reason not to use those objects.
It's not a good practice to pass the EF objects directly to the web project. As the state changes occurring in the EF objects can directly reflect on the database. Because of this you should explicitly define POC objects for web project.(we can call this as Data Model or simply Model. The POC object used for retrieving data from the View can be called as View Model. In appropriate situations you can use the same POCO class as a Data Model as well a View Model)
I have an MVC 4 app that I am working on and using the code first implementation except I cheated a bit and created my database first then generated my entity classes (poco) from my database using the EF power tools (reverse engineer). I guess you can say I did database first method but I have no edmx file just the context class and my entity classes (poco)
I have a few projects in the works using MVC and EF with pocos but just the one project I used the tool to generate my pocos from the database.
My question is about the mapping files that get created when I generate my pocos using the tool. What is the purpose of these Map files? I figured the map files are needed when generating the db from the model like with the true code first method, in my case where I am using a tool to generate my model from the database do the map files have any influence on how my app uses the entity classes?
The mapping files are to fluent files help Code First generate the database from your model, as well as help EF create the proper relationships.
They can map properties - things like setting a primary key, max length, data type.
They can also map relationships - set things like foreign keys, and defining relationships that don't follow standard CF naming conventions.
Even though you're not generating your database from the app, CF will use this system to ensure that the database it's pointing to is compatible with your model, and in the case of foreign keys and things setup related properties. For example, if you wanted to name a FK something other than NavigationPropertyId, you would need fluent to tell the engine what property to set in the database.
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.