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.
Related
I'm starting from a point very similar to: Domain Entities, DTO, and View Models.
The advised use of DTOs to map between the domain model and the MVC's ViewModel seems consistent expectations. I seek details of how to bridge the domain model (Entity Framework-based project) to the WebAPI mvc project.
I'm starting with a project of simple POCOs (generated by EF PowerTools to reverse engineer my existent db) that I want to connect to an MVC4 WebAPI project.
I expect I'll be adding business logic to the baseline POCO project as my solution evolves and perhaps this is the crux of this issue. The business logic that transforms the POCOs into something that can be mapped to the MVC project.
Exactly how do I wire these projects together so i can start creating controllers in the MVC project that knows about the entities of the EF project? Automapper? Can we point to posts/docs where this specific feature of Automapper is employed?
You don't want controllers that knows about the EF entities - that's the whole point of this. :)
You yourself say that the DTOs should be used to map your domain to your view model, and then you ask "how can I bridge my domain model with the mvc controllers?". You've already answered this - with DTOs!
The DTO serves as a transport layer between complex business objects and models used to display a certain view. Both of these have special requirements that don't strictly relate to "just data" - hence using DTOs will give you a greater decoupling and separation of concerns.
If you don't decouple domain from view model, you will be forced to directly reference your EF objects in your view model code, which exposes unnecessary data and functions "up the chain".
Now, if you use WebAPI as a way to ship data then I think you could usually get away with sending the DTOs, since WebAPI data usually wouldn't be implementing view model logic. But YMMV of course, depending on how you plan to use your controllers.
For AutoMapper I'd say it's best to start with their own docs (they even use DTO examples in them): http://github.com/AutoMapper/AutoMapper/wiki/Getting-started
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.
I have an ASP.NET MVC 2 application with a POCO domain model and an NHibernate repository layer. My domain model has no awareness of my viewmodels so I use automapper to go from viewmodel to entity and vice/versa.
When I introduced WCF to my project (a late requirement), I started having to deal with disconnected objects. That is, I retrieve an entity from the database with NHibernate and once that entity is serialized it becomes disconnected and each child collection is loaded regardless of whether or not I plan on using it meaning I'm doing alot of unnecessary database work.
After reading up on this, I see that it is highly recommended that you not expose your entities outside of your domain project and you should instead use DTOs.
I see the reason for this but I'm having trouble figuring out how to implement it.
Do I map from viewmodel to DTO in ASP.NET MVC, send DTOs through the service layer, and map from DTO to entity in the service layer? Where should I define my DTOs?
I like to have my service layer keep entities encapsulated within it, and return/receive only DTOs. I keep the service contracts as well as the DTO's in a separate assembly which both the MVC project and the Service implementation reference.
Inside the service call implementation, the service maps dto's to entities, then does the interaction with repositories and other entities as it needs to.
On the app/mvc project I sometimes will get lazy and just use DTO's as the models for certain actions (especially CRUDy ones). If i need a projection or something like that, then I'll make a viewmodel and convert between DTO and viewmodel with automapper etc.
How exposed your entities are is a subject of much debate. Some people will push them all the way to the view/app layer. I prefer to keep them in the service layer. I find that when the entities leave the service layer, you find yourself doing business logic type stuff anywhere where they're interacted with, stuff that should probably reside in a service.
I treat my DTOs like ViewModels because the UI layer ( MVC app ) is requesting them. You could go Entity -> DTO -> ViewModel but I think thats over engineering if the only consumer of your service is an MVC application. If somehow the DTOs will actually be used for data and not simply screen specifications then you should probably use additional mapping.
I've also simply returned entities from my WCF layer and let the automatically generated proxy objects on the client be the DTO. The entities almost become DTOs because of the proxy classes and no business logic comes over to the client.
And of course, this is all "It Depends" what your architectural goals are. This question is borderline subjective and argumentative IMHO.
I like defining the DTO in the MVC project and then creating extension methods to transform from domain entity to DTO (and vice-versa).
The transformation would take place in the mvc functions.
I just wrote a post about a way of getting around all this DTO <-> DO transformation. Maybe you check it out http://codeblock.engio.net/?p=17
Although I believe I have a good grasp on MVC (from Rails), I'm learning the "MS Way" with ASP.NET MVC.
Also, I am learning Entity Framework as well.
I've created an Entity called User in my Models folder. Using LINQ to EF I can retrieve records and all is good.
Now, I want to put some business (or what I call, domain) logic in. But in my mind, EF is more of the DAL. So I created a folder called "Domain" and in there, I created a class for some business rules.
One of them is to encrypt passwords.
So I can use the following in my controllers:
string password = Domain.User.EncryptPassword(string salt, string password);
Also, that means the domain logic can access the EF User when it needs to persist to the DB.
Is this logic sound?
Any recommendations appreciated.
Thanks!
The only thing I would ask is: "Why would a user, a person, know how to encrypt or hash a password?"
Encrypting a password would be part of an Application layer. This is almost anti-DDD.
It depends a bit on the project, but generally we:
do not put any code in the EF models, all models are stored in a seperate project
place a business layer between the MVC code and EF. In previous versions of EF this would be used to map EF objects to domain objects, but with POCO this is no longer needed. Any caching would be done in this layer.
use a helper or utility class for encryption
I think what you are looking for is POCO (Plain Old CLR Objects). In one hand you have your EF entities. In the other hand you have your Domain or Business Entities... and then you can map them... your DAL Layer must return POCO entities and not EF entities.. at least that's how is made in a 3-tier application. I suppose it's the same approach in a MVC application...
Am I right?
I'm new to MVC and even though there is a lot (and I do mean a lot) of information out there that is very useful - it's proofing very difficult to get a clear understanding on how to achieve my exact requirements with MVC 2.0.
I would like to set up a solution as follows:
Provide a web UI using an MVC 2.0 project.
Use Linq to SQL classes project for data persistence.
I have a two separate code modules that will need to access the above Linq to SQL model - so I won't be able to include my Linq to SQL model directly in the MVC project itself.
Also I have a Business Logic layer in front of my Linq to SQL project.
My questions are:
How do I set up the Model part of my MVC application to point to my Linq to SQL project via my BLL?
How do I perform web app validation? Can I use MVC 2.0 Model Validation? If not what are the alternatives?
Finally (and slightly aside) - What is the ViewModel and how does this differ from the Model?
So many questions. But this is an exciting new technology and data access issues aside, everything else I've got to grips with very quickly and I think MVC 2.0 is fantastic.
Thanks for any pointers you can provide.
How do I set up the Model part of my
MVC application to point to my Linq to
SQL project via my BLL?
Typically you'd use a repository pattern for this. Your controller has a reference to your repository - the repository returns your domain objects from your database. The MVC app has no knowledge LINQ to SQL exists.
How do I perform web app validation?
Can I use MVC 2.0 Model Validation? If
not what are the alternatives?
Put view models in your MVC project. These view models may closely align with your domain models but their concern is to be the presentation model. Put your data annotations for validation on these view models - the MVC framework will automatically ensure validation occurs on these view models decorated with data annotations. It's pluggable so you could use alternatives - but with MVC 2, it's baked in fairly well and this includes client side validation.
Finally (and slightly aside) - What is
the ViewModel and how does this differ
from the Model?
I partially answered this one above. the shape of your domain models may not be the shape you need to display your views - view models are great to bridge this gap. Additionally, even if the shape does match exactly - view models are still a good idea so that you can put UI validation code there and other presentation meta-data on them (since you do not want anything related to presentation logic on your domain model).
Here's link for view model patterns.
Hope this helps.
You can add a reference to the objects exposed from your BLL assembly and use them as your Models.
When you want to add validation to classes that are generated use buddy classes.
A ViewModel is a custom-shaped aggregate of Model data. There is exactly one per View, as the ViewModel's purpose is to surface exactly the data needed by a particular View in a convenient and concise way.
An example might be a View that contains both Order and OrderDetail information. A ViewModel can hold internal references to the repositories and business objects for each type. Properties of the ViewModel merge together the data from these objects.
ViewModels will be useful in your case also because you want your Models to be in a separate assembly. You can apply the DataAnnotations to ViewModel properties for validation. You would make the "raw" business object models internal properties of your ViewModels, and expose public methods to retrieve and persist data.