As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I would like to know the pros and cons of using EF4 Code-First approach. Can we duplicate all features that EF4 generated classes offer like Lazy Loading, loading related entities, etc?
Thanks
Pros
Lightweight entity classes or POCO based.
More control over entity classes since you code them yourself rather than depending on EF to generate them. This means you don't have to define partial classes to do data annotations.
Option to never have to specify mapping anywhere. Convention takes over configuration.
DbContext follows the repository pattern.
Lazy loading, related entity loading all taken care of for you. For example a Post model can declare Author model in the POCO and EF Code first will map this relation automatically. Again use of convention makes us so productive.
Works great for greenfield applications.
ASP.NET MVC view generation works great.
ModelBinder works as per normal.
Cons
No API support for customizing the database mapping convention like in Fluent nHibernate.
Bit difficult to map to existing databases.(This might change in the release version).
For sample code and mapping to existing databases using EF 4.0 Code First see this blog post.
http://theminimalistdeveloper.com/2010/07/28/how-to-map-pocos-to-existing-databases-in-entity-framework-4-0-code-first-and-asp-net-mvc-2/
Cons:
Since you have no EDMX, you can't pregenerate views
Not yet licensed for go-live. Hopefully, this will change soon.
Pros
Since there is no fixed schema, you can dynamically build one at runtime.
Most other things are exactly the same (lazy loading, explicit loading, etc.). A few more are matters of personal preference (the API).
Since you asked specifically about Lazy Loading, here's a writeup showing Working with Lazy Loading with Entity Framework Code First, where it's enabled by default. To specifically answer that part of your question, yes with Code First you still get the benefits of Lazy Loading, and in fact as the post shows, you have very fine-grained control over this feature.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Tearing-hair-out here. I'm trying to link an entity type (say "Customer") to the UserProfile table in a Code-First Application. I don't want to put my domain information into the automatically-generated UserProfile table, I want it in my domain table.
I've added a public virtual UserProfile UserId { get; set; } to the abstract base of my domain class, but update-database keeps saying No pending code-based migrations.
I'm still in early development, there's nothing in the DB I want to keep is there a "nuclear option" to get the migrations to "forget everything" and start over? update-database -targetmigration:0 doesn't seem to do much for me.
Edit: I nuked the database & started over, and migrated the fields from the abstract class onto the concrete class, and bob's your uncle. I just have this awful collection of types with tons of replicated fields and lots of replicated code to deal with two "different" types (that are really the same).
This has been, without a doubt the WORST experience I've ever had with a technology BAR NONE.
I guess my question is, after a week of reading articles, watching Pluralsight videos & beating my head against a brick wall repeatedly, is this how people actually work with this technology? This is AWFUL.
If this is your first venture into ORM expect to be frustrated no matter which framework you use. ORM's can be tricky to wrap your head around. You are moving between OOP and normalized database tables. It takes some practice.
The nice thing about entity framework is that most of the time it saves you the hassle of having to map relationships yourself. Not sure if you can do this with NHibernate yet?
The downside is that occasionally EF gets it wrong, and it can be hard to sort out what the heck happened. It relies heavily on conventions, which are pretty straight forward if you know what they are.
It's just like when you first started coding and you were like "what the hell does null pointer exception mean!" It takes a bit to get your bearings. Once you get some practice with it though it really speeds up your dev time.
Try posting your model. I may be able to help you get back on the right track.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a transformation sequence of models that eventually outputs an EMF model, instance of some EMF Meta model (the meta model I defined myself).
I am looking for a good way to generate code from this. Of course, there is XPand, I used to use that for other projects, but I wonder if XText or XTend is a suitable alternative (since it's so actively developed).
In other words, I have an EMF model, don't need an editor for it (so don't need XText for THAT purpose), but I DO need to build a code generator. Could I use XText for only that part?
And would it be advisable over XPand or Acceleo?
Any advice would be great.
I try to do a fair comparison between the tools, but it is really hard.
Xtext has nothing to do with code generation - it is for creating editors and parsers.
Xtend2 is designed as a successor of Xpand with a similar syntax - however, it is not tailored specifically to code generation but as a general purpose language that is nicely usable for code generation as well. The main difference between other generation engines is that you work on the source code level (basically, Xtend2 translates to Java), and you have to provide your own engine that drives the generation - although of course it is possible to use Modeling Workflow Engine for this reason - just as in case of Xpand.
Acceleo is more tailored for simple code generation. It's syntax is based on an OMG specification for code generation, and provides a full-featured IDE for developing code generation. However, if you need complex control structure during code generation, it might be not the best solution.
About M2T-JET, as Chris suggested, I would vote against, except for very specific needs. It's development support is much weaker (e.g. it's editor), and is more based on the idea of having a single template for output opposed to a higher level, rule based approach of Xpand/Xtend/Acceleo. This results in somewhat better performance during code generation, however, it often results in harder to understand templates. Ignore this paragraph because it is too negative.
Alltogether, if you are using only EMF models, both Acceleo and Xtend can be a nice choice for code generation, and you should choose between them based on your (or your teams) expertise and your more specific needs. If you need to support both EMF models and other data sources, then Acceleo is not the best choice; however, neither JET nor Xtend builds on the fact that your input is an EMF model, but provides easy way to call any Java code available.
I recommend M2T-JET. It's a text template based transform that uses multiple templates to generate projects, folders and files from a single input model. The model can be EMF and the templates let you navigate through and iterate over the model to produce the Eclipse resources you have in mind.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am about to start a new project that will use the Play! 2 framework for Scala, probably using Squeryl as ORM (but maybe Slick would be fine too, if it ready in time).
Now, Play! has a feature to upgrade your database using migrations. Unforunately, these migrations are written in SQL. This is not only an inconvenience (I would like to be able to write migrations in Scala) but has two problems
first, I need to write migrations on my own. I am used to South, that is able to infer schema migrations by looking at the current and previous definitions of my models;
second, it would be very cumbersome to handle data migrations. One may have the need to alter data programmatically, and this may not even be doable in plain SQL.
So, I am looking for an alternative. I was not able to find any migration tool for any Scala ORM that would generate schema migrations automatically, is there any?
The best tool I could find is Scala migrations. Is there a way to make Play! automatically use it in place of its own migration tool?
Another alternative is Flyway, but it will not solve your integration issue.
For that, either you can implement a Plugin as it is done with standard Play! evolutions, either you could use the Global object to start the migration on the application start.
Evolutions in Play2 is implemented as a plugin. You could examine its implementation and roll your own along the same lines. As far as I can see, there isn't a simple way to just swap out the implementation for another.
One other tool that might be worth looking at is Liquibase. It is implemented in Java so should be easy to use from Scala.
I recommend liquibase. Liquibase is an open source, database-independent library for tracking, managing and applying database changes. It is built on a simple premise: All database changes are stored in a human readable yet trackable form and checked into source control. Liquibase can be used for both Java and Scala. The great thing about Liquibase is that you can use either XML, SQL, or combination of both for your db migration needs. It is easy to set up and use and has very extensive documents.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
My team and I are beginning to plan the development of a modular application which will likely multi-target WPF & Silverlight.
I personally have some experience using the older version of PRISM to build a composite Silverlight app using the MVVM pattern. We weren't familiar with MEF at the time for handling the various module dependencies, so we didn't use it.
We aren't married to any particular framework, but want to use one of the bigger players out there. As such we've begun to examine Caliburn/Caliburn Micro, Prism, MVVM Light and Reactive UI.
Most of what I've read for modularity suggests PRISM and MEF to handle that part of the process. As I'm still wrapping my head around some of this, I'm not sure if I'm missing some obvious options. I was able to find this article on Caliburn Micro and MEF.
Can anyone point me to similar articles using some of the other frameworks to compose a composite app similarly to the way PRSIM uses Regions, etc? Ideally, I'd like to limit the number of frameworks needed while providing maximum flexibility. We aren't averse to taking a "best of breed" approach and using for example MEF/PRISM to handle the compositing and MVVM Light for the View management, etc; but why use 2 when 1 will do?
One thing you should probably do first is isolate these into their appropriate buckets. I see this a lot where people will mix MVVM frameworks with application composition frameworks. Once you have them in the appropriate buckets you can start to pick one framework from each category and combine them into what you consider to be the best scenario.
Application Composition
Prism (using any IoC container: MEF, Unity, Ninject, Autofac, etc. There are a few things that make MVVM easier with Prism, but I wouldn't call it a fully featured MVVM framework... it's primarily a modular application composition framwork.)
MEF (MEF is actually able to do application composition out of the box. It's often dismissed as just an IoC framework, but it is deceptively powerful.)
MVVM Frameworks
ReactiveUI (my favorite)
Caliburn
Caliburn Micro
MVVM Light
This will help you make a decision, I think. You can pick and application composition technology you like and an MVVM framework you like and be off and running to the races.
As for articles, I don't have too many. There are a lot of good articles on application composition with Prism (that's pretty much its job), but here is a good article on application composition with MEF by itself:
http://blogs.microsoft.co.il/blogs/tomershamam/archive/2009/08/11/wpf-mef-declarative-composite-ui.aspx
You should also check out Glenn Block's series "Building HelloMEF" on his blog. I couldn't find a comprehensive list (he wasn't consistent with his tagging), but here is the "MEF" tag. Lots of good stuff here:
http://blogs.msdn.com/b/gblock/archive/tags/mef/default.aspx?PageIndex=1
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Yesterday I was reading some articles in this site while I stumbled on an article about this two new IoC tools. Which one should I learn first? Is there some specification about which one should be used when?
Neither Castle.Windsor or Spring.NET are new.
Castle Windsor have been around since late 2004
Spring.NET have been around since early 2006
They are two comparable DI Containers that essentially aim at providing the same services, so you don't need to learn one before the other, and neither do you need to consult any kind of specification on when to use which one.
I've been using Castle Windsor for about half a year and am generally happy with it. Spring.NET I have yet to look at, but it looks like it is very closely tied to the configuration system and doesn't support programmatic registration, and if this is true, that would be a major drawback in my eyes.
Castle Windsor and Spring.NET are not the only DI Containers available for .NET. Here's a larger list:
Castle Windsor
Spring.NET
StructureMap
Unity
Ninject
autofac
I'm one of the committers to Castle project (which includes Windsor) so I may be biased, but.
Windsor is very extensible, allows you to tune and bend it to your needs. It provides nice fluent registration API so that you don't have to write ton of XML. There are also tons of extensions that you can use to integrate Windsor with other frameworks, like ORMs communication frameworks (WCF, NServiceBus) etc.
Plus it has a very active and responsive community, so if you have any questions, they'll get answered fairly quickly most of the time.
I guess both are better in terms of configuration. No much difference but both are better than Unity framework. Why the hell you need marshalbyrefobject association in dependency control. But if we compare spring.net and Castle Windsor both are good. But question comes which one is complete container framework.
Like we need Aspects for validation on Dependency. So winsor utility fail. I guess it’s stupid to compare String.net with Castle Windsor or anything like such because all are utilities and spring is complete container framework. And all folks who say it’s heavy please check memory leak issues with all. It’s not spring or Castle Windsor , it’s stupid way of writing code.
So finally answer is if you need just DI use Windsor but if you need complete framework for any solution use spring.net.