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.
Related
When using Entity Framework with Code-First, what is the best practice when calling database data?
This is my first time using Entity Framework with MVC and noticed that it automatically builds Models in my DataLayer. I also have the basic Models within my MVC UI which allow me to manipulate and display the data within my Views. I currently grab the data using my Workflow layer, and then AutoMap the Database Model to my UI Model to display the data.
Is this the best practice? Should I be using the Entity Framework Models instead of my UI Models? Or this even possible to do cleanly?
Any information on the matter would be appreciated.
It's up to you really. If you like to re-use the same EF entities for your view models as well; go ahead. Personally, I prefer not to. This is because you normally end up adding a bunch of properties to the class that have nothing to do with what's stored in the data and yes; I know you can use the NotMapped attribute like this:
[NotMapped]
public string MyExtraProperty { get; set; }
but I prefer not to. Additionally, you end up adding [Display] and other attributes to your properties and before you know it, you've got something decorated with both data specific and UI specific attributes and it can get messy if you're not careful.
So for me; I have the following:
Domain Entity
View Model
Service/Facade/Repository
Controller calls repository to get the domain entity and converts it to a view model for displaying.
I find that to be a cleaner approach, but maybe that's just me.. the most important thing is to just choose one way and stick with it for the sake of consistency and clarity of code, but either method is acceptable.. "whatever floats your boat" as they say...
The POCOs created by EF are supposed to be used as your model. The general idea is that you have EF providing access to your database. You query EF using LINQ and/or extension methods and end up with an object or collection of objects that you display on your UI by binding them in WPF. That is of course if you're using WPF as opposed to the older WinForms. I can tell you from experience that it's a very streamlined process once you become familiar with the technologies. That's how a very basic setup would work.
A more advanced way of going about it is adding architectures like Model-View-ViewModel (MVVM) and possibly the repository pattern into the mix at which point you get better separation of code and presentation at the cost of increased complexity.
I don't know what flavor of MVC you're using and how it can be made to intermingle with the above, but if you want to know more about how EF was envisioned to work you should look into the technologies I've listed above.
I have a database name CostDB on a SQLserver. I need to create a page (ASP.Net MVC 4) with a simple dropdown list (i.e. Company Name) which will be directly bind to the Company column of DESE table from the CostDB database.
I am lost after looking at all tutorials and ASP.Net MVC4's own tutorials that what way to start? There are different ways of code first, model first etc. I already have the database. Do I need to create a Model first in this case? If so does it have to be exact name match from the DB table names? Or do I generate the model from the database?Which functions would I need to create if I need to show data in the dropdownlist on page load? Most importantly what is the order to create an MVC application for an existing DB. Among M,V,C, what to create first?
Completely new to ASP.Net MVC 4. Already did go through MVCMovies tutorial but with no luck. Any suggestion would be really appreciated.
I think the best answer is this: Whatever you are comfortable with and what works for you. There are tons of different approaches to development, and variations of each of those approaches. I tend to lean towards database first, as I don't have as much experience in code first.
Since you already have a database created, I think the easiest approach for your method would be to generate an EDMX off of your existing structure and go from there. Once you have the EDMX built and all the appropriate files referenced, it should be easy. Just populate a list from your EF model, toss it into the ViewBag, and then populate your control(s).
Here is a good link on how to do this. Populate #Html.DropDownList with a List using MVC
I would highly recommend PluralSight for learning any type of development, one of the best sites I have ever used. Best of luck!
I have been doing ASP.NET MVC at university this year and only touched on some of the basic principles but absolutely loved it. Having been a PHP fan for over 6 years I planned to use something like CakePHP to continue using the MVC pattern in my work.
However I have a few questions as their are MASSIVE differences between the two frameworks:
1.) How would someone do something similar to LINQ where when ever you do your actionresult you can simple build a query and then return it to the view?
2.) Do repositories exists in Cake? I love these in ASP.NET and the ability to create custom methods for your database logic and then call them anywhere.
3.) Confusion with the model. In ASP.NET I could have a single model deal with lots of tables and then call any table or combination of tables with ease. In Cake it seems you have a model per table???
CakePHP comes with its own persistence API, whereas in ASP.NET MVC you can (and have to) use something else of your choosing.
1) There isn't an equivalent to LINQ in CakePHP, but you can still construct queries pretty easily.
2) CakePHP's models can have functions attached, and they also have something called Behaviors which are neat.
3) CakePHP's persistence system associates one model with a persistent entity (such as a table). I'm not sure I can give a better answer with out a more specific example.
I did a lot of PHP work before I moved on to .NET. While I still like ASP.NET MVC or RoR better (mostly because they are better frameworks and languages, IMHO, than PHP), the few projects I did in CakePHP were very pleasant.
I am not familiar with ASP.NET, but I can answer some of these questions.
LINQ... I am not familiar with. If
you could give a simple example, I
could explain if there is a similar
method in Cake.
The Repositories you refer to can be
Behaviors as mentioned by
#HackedByChinese. However, you may
have better results by adding
functions to the app_model.php file.
All models in the app can access any
function in the app_model.php file
which can be added to your app
directory.
Yes. CakePHP is designed with code
separation in mind. The idea behind
a single table per model allows you
build a very FAT model and still
keep it manageable. You build all of
the relationships, validation, and
other model specific code into each
model. Then when something goes
wrong with Users for example, you
know you need to look in the Users
model. This can be overridden, you
can put all of the model access into
a single model file if you want, but
it makes the code sloppy. If you are
going to do that, why use Cake? Just
put all of your model code in
Model.php, all of your controller
code in Controller.php and all of
your view code in View.php and call
it good. I think you would agree
that is not the structure for very
readable nor extensible code.
Quick question about database views. Am I right in assuming that I can create a database of view of various tables and connect them how I want etc and then when I do queries, add, edit delete etc then MVC will figure it all out for me without needing to do any complex SQL in the controller or repository?
Odd question but just wanted to make sure my assumption was valid. Cheers
Unfortunately, MVC will not figure it all out for you, you'll still need to write the SQL code (or use an ORM framework) to communicate with the database.
What MVC gives you with it's architecture is a clear separation of responsibilities:
Views are responsible for displaying data and should be as simple as possible (i.e. little to no logic in them)
Model(s) contain the business logic and rules
Controllers are responsible for passing data between the Model and the Views.
What you are looking for is Scaffolding. In .net MVC I can't think of any tools which do this for you directly against the database. They all require either as Russ said an ORM i.e. Linq To SQL or Entity Framework (EF).
http://msdn.microsoft.com/en-us/library/cc488540.aspx
The closest you could get would be to use Database First model generation and then put the necessary MVC templates/views/code on top.
A database view is read-only so you will not be able to perform write operations on the view. You can however create a model from a view and display your data as defined from the view. If you are using an ORM solution such as ADO.NET Entities you can instantiate an object and add the child objects to it and be able to save the final result in a single transaction as well.
Having used all of them (some more than others), I am still undecided on which could be the best to use (with .NET 3.5). What are the pro's and con's of each when developing?
SubSonic 3
Not enough samples/documentation (I know its a wiki and people can update it, but it can be tricky to track things down - e.g. where are the sample apps (WebForms, MVC (current version, rather than pre-3), WinForms)). Text Templates didn't work as expected when I first tried them. For example, it does not clean up the table names like SubSonic 2 did (removing/replacing spaces for example). Also, you cannot say which tables to include, just the ones you can exclude (in ActiveRecord.tt). Context.tt and Structs.tt generates code for all the tables (you would probably not want the 'aspnet_' ones, and probably some others (session tables) as well).
Saying that though (hope I'm not being too harsh), it is quite a good ORM to use, minor issues aside.
Entity Data Model (Entity Framework)
Visual Designer for setting up models. Syncs with database, might be considered a bit 'verbose' and hard to understand. There is fairly decent documentation though. Not gone that much further in depth though.
LINQ to SQL
Also has a designer for creating models. Simple to use. Less features than the other two. I also had to apply a hotfix for an obscure bug (wouldn't update when the model had foreign keys that were not of type int)
NHibernate
Looked at this in the past, but not that easy to set up compared to the above.
Any sample ASP.NET MVC apps using this?
Ideally I would want a framework that:
a) could generate the models from a database
b) support LINQ syntax
c) retrieve only the data that is needed (e.g. for paging)
d) allow data annotations
e) could generate the sql to update or create new tables in an existing database
MVC is presentation layer, ORM is Data layer
I don't think that ORM has anything so much to do with an MVC application. At least if you tier your application properly. Model in an MVC application is rather model of the presentation layer view. A view model through which controller and view communicate. Not necessarily data model. MVC project template is a bit confusing, since developers think that MVC model = data model. In any business application that is not completely trivial (like a single assembly simple application) this is not equal. And it's better that its not. Especially if we take into cosideration separation of concerns. We shouldn't rely on particular ORM classes in any layer other than data layer.
But if you intend to use DTOs in your MVC application (as view models) I suggest you use that ORM that creates partial classes, so you can easily add additional stuff on them (like attributes). Your data annotations can be written inside of a special metadata class that can be attached to your model class by a single class-level attribute.
Suggestion
But I suggest doing something else. Use a separate layer with POCOs that will be used on all layers and would have data annotations on them. This will make your presentation layer independent of data layer and your POCOs may also be presentation optimised (like having a class called UserRegistration for instance with two password properties - with repeated value as well). Your repository in your data layer would be responsible for POCO conversion so all layers will exchange data using POCOs only instead of using data objects.
ORMs and class generation
With Entity Framework you do get a very controllable environment to generate your classes from a data store schema. Unfortunately it's not the same with others. Generateion is not all-in, but can be controlled and manipulated manually as well (if you'd like to do TPH/TPT structures).
Similar with LINQ to SQL. I haven't used any other ORM but I guess LinqConnect may have it's own editor similar to EF Visual Studio editor, because I've been working with MySql connector from the same company and I've used their designer for entities because it was better than the one provided with Visual Studio 2008.
But you have tools that provide code generation (and you can get templates on the internet for various ORMs as well):
there's T4 built into Visual Studio that can generate code for you; You can as well fint templates for ORMs written in T4 that you can then easily customize. Or write your own acording to your needs (I've written enumeration generator from DB lookup tables in the past)
MyGeneration is open source and you can find lots of templates for it
CodeSmith is not free but is a proved product that I've used in the past with .netTiers template (before we had LINQ) which saved lots of time and worked perfectly