I am following Steven Sanderson's "Pro ASP.Net MVC2 Framewok", which uses Linq2SQL. He uses abstract factory approach to support unit testing and mocking, and writes model classes in a separate project to facilitate this.
I am using Linq to Entity Framework instead of Linq2SQL, and I have built an entity model in EF from an existing database. (I am new to all of this).
I don't quite understand if I'm getting this right, but I beleive I should still generate model classes defined outside of EF (a layer between EF and presentation?), even though I could just pass Linq2EF query results entities directly in as MVC's models (security? separation of concerns?).
So I'd like EF to stub the model classes for me instead of hand-coding them all from scratch. Is there an easy way to do this, or am I mis-interpreting what I need to do?
Take a look at this blog great resource on this subject.
If you are going to use ViewModels I highly recomend using AutoMapper from souceforge
Related
I am learning asp.net MVC, as I have been using the sqlconnection, sqlcommands etc from my initial phases, I would like to initially start learning asp.net MVC without using the entity framework.
Can you give me a link or any idea of using the models to process data without using the entity framework.
So without entity framework you'll be using ADO.NET (See MSDN)
Those classes you mentioned SqlConnection, SqlCommand are part of the ADO.NET framework. The two Microsoft frameworks that build on this are Entity Framework and LinqToSQL.
If you don't want to us either you have to write you own models/classes, and then methods to persist those models into your database. (This is essentially what EF does) You won't get any LINQ or designers etc.
Also, ADO.NET does have a way to create strongly typed datasets. This might help a little.
What you are doing might help you understand whats going on under the covers, but do realize frameworks like Entity-Framework save a lot of time and effort by generating models for you.
I have read here 3 approaches towards implementing POCO with entity framework namely
Create edmx model and turn off code generation so the model will not create heavy entities for you. Then you will create your POCO classes which have to follow some restrictions.
You can use the POCO template which can be downloaded to VS 2010.
Use Code First approach where you code your POCOs and you define mapping in code. To do
this you need EF 4.0 Feature CTP from here.
I was personally going to opt for the second approach as it is quicker but what are the things that I should keep in mind since it derives from ObjectContext I guess it is in a way coupled? I know the third approach gives the most flexibility but is it worth it ? Please share your thoughts regarding this..Thanks!
That link you have provided for "POCO Template" is broken - but i assume you mean this:
http://visualstudiogallery.msdn.microsoft.com/23df0450-5677-4926-96cc-173d02752313
This template can (and should) be used in conjuction with Option 1 you have stated.
That's what i use in my current application:
1 - Create EDMX Model
2 - Turn off code gen
3 - Use POCO Generator to generate POCO classes
The POCO's do not derive from anything - they are pure POCO's.
I found these two links to be invaluable when setting up my model/poco classes. Poco generation and Poco options. As mentioned above it is a good idea (certainly if using the repository pattern) to turn off code generation in the edmx and create both a derived ObjectContext class and your Poco classes via the two T4 templates provided by Microsoft.
If you use the T4 templates without making any changes to them then you will get a set of Poco classes with the "Change Tracking Proxies with Fixup" option enabled in the generated code.
Is there anything that would aid us in designing/scaffolding View models from SQL Server database tables but would result in very lean classes? I know something like that exists for Rails, maybe there's something similar in ASP.NET MVC?
I like what EF wizard creates but it's too heavy - too much attributes, constraints, events and everything is attached to the entities so you can't actually use them as View models (actually you can but it quickly becomes a pain).
I think you could use a POCO generator for your EF4 model instead of the default one. This is a link explaining how. LINK
I hope you can adapt it to fill your needs.
A POCO Class(Plain Old CLR Objects) is by definition a lightweight class, that is (maybe) what you're looking for.
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?
In my first ASP.NET MVC applications, the model was a simple O/R mapping between a table and the classes, managed by the Entity Framework.
Now I would like to add some meat to this skeleton, and introduce business methods for the generated classes. What is the recommended approch to this in ASP.NET MVC (with Entity Framework)? My favorite would be solution which also can be used in a service layer, with no ASP.NET MVC references, so that the same domain logic also could be reused in a desktop client.
Technically, I think it should be possible to extend the generated classes in a way which preserves the additional business logic even if the O/R classes need to be refreshed. (This is more a question related to the Entity Framework however.)
Edit: Many thanks for the contributions, and the information about the next version of Entity Framework (4.0). Building two sets of classes, one auto-generated to represent the data in the persistency layer and one for the actual business logic sounds interesting.
Within MVC.Net, the model is the least clearly defined part. In my opinion, it's basically the rest of your application (i.e. anything not related to the View or the Controller). The O/R Mapping part of your application should probably be outside of the "Model" also, as this is more of a data layer. The Model, should really deal in business objects and create views of your data to pass to the View.
There are lots of differing opinions on this, but I think it's best not to think of MVC.Net as traditional MVC Architecture.
If you are using EF v1.0 right now, the Entity Framework is very intrusive into your application, which means that you cannot create POCO very easily. The way you can extend your model is by using the partial class. So when you refresh your model, the partial class you did will still be valid. The Entity Framework team realizes this is a problem , and have improved this in next version (EF V4.0).
NHibernate is much more friendly and allow you easily extend your business logic.
I really think this blog post by Jeremy D. Miller is very good at pointing out the problem.
Abstract your Business Layer out into another project, then pass an instance of it onto your mvc controller using something like structure map. You can then call this Business Layer from your controller to retrieve your business entities (Model) and pass them on to the UI. This will allow you to resuse your Business Layer in your desktop application.
Not only meat but also some clothes and a style could be added to this project to make it seem chic. It depends on the time you have for the project. If you have time, I could suggest you to get a look to TDD and the frameworks that could be used with TDD such as Castle, NUnit, Moq etc.
As you mentioned a service layer is a must for any project but with these kinds of frameworks you could design your architecture more robust.