Closed. This question is opinion-based. It is not currently accepting answers.
Closed 7 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Some people consider WordPress a blogging platform, some think of it as a CMS, some refer to WordPress as a development framework. Whichever it is, the question still remains. Is WordPress MVC compliant?
I've read the forums and somebody asked about MVC about three years ago. There were some positive answers, and some negative ones. While nobody knows exactly what MVC is and everybody thinks of it in their own way, there's still a general concept that's present in all the discussions.
I have little experience with MVC frameworks and there doesn't seem to be anything about the framework itself. Most of the MVC is done by the programmer, am I right? Now, going back to WordPress, could we consider the core rewrite engine (WP_Rewrite) the controller? Queries & plugin logic as the model? And themes as the view? Or am I getting it all wrong?
Thanks ;)
Wordpress itself is not architected in MVC, but one can build very MVC oriented themes and plugins within the framework. There are several tools which can help:
WordPress MVC solutions:
Churro: # wordpress.org/extend/plugins/churro
Tina-MVC: # wordpress.org/extend/plugins/tina-mvc
Plugin Factory: # wordpress.org/extend/plugins/plugin-factory
MVCPress: http://mozey.wordpress.com/2007/01/22/mvcpress-screenshots/#comment-3634 (abandoned, but interesting ideas)
MVC threads on WordPress.org Ideas and Trac:
http://wordpress.org/extend/ideas/topic/mvc-plugin-framework
http://wordpress.org/extend/ideas/topic/complete-reestructuring
http://wordpress.org/extend/ideas/topic/rewrite-wordpress-using-mvc
http://wordpress.org/extend/ideas/topic/wordpress-theme-revamp (more on XSL than MVC)
http://core.trac.wordpress.org/ticket/12354 (on MVC in widgets)
Wordpress is kinda-sorta MVC. If anything it is a pull-type MVC layout, where the View 'pulls' data from the model. It does this in a very proceedural way, instead of using lots of different objects, but this actually makes the front end templates easier to write in a lot of ways.
This also gives the views some degree of controller logic (thus the kinda-sorta MVC).
Lets run this down:
Wordpress gets a URL. The wordpress core acts as a controller and determines what initial queries to run of the database, and by extension, what view should be loaded (category view, single post or page view, etc). It then packages that INTIAL query response and sends it to the view file.
That view file CAN be a strict display only file OR it can request additional information/queries beyond the built in one. This is the pull-type of the MVC, where the view pulls data from the model instead of the controller 'pushing' data from the model into the view.
Thus, when the view sees code to load a sidebar or widget area, it asks for that information. However, what widgets should be there is determined by the controller, which looks at the model for what widgets are in the sidebar, and then selects those that are set to show on the current page, and returns those to the view.
That each part of that isn't an object doesn't make this any less MVC. You can alter WP core without (necessarily) altering anything about a theme. Similarly, as long as you use built in functions like 'get_pages()' then the model and the database tables could change as long as those functions still returned the right data. So, the model is independent of the view, and the controller is independent as well (except when the view adds controller logic to do more than the core normally does).
While you COULD have a model object holding a number of methods and stuff like WPModel::get_pages('blah blah'), and contain everything that way, there is still fundamental separation of concerns.
View: template files
Controller: WP core
Model: the various functions that handle specific data handling.
As long as the names, arguments, etc, stay the same (or just have new ones added) then separation of concerns is maintained and one can be altered without disturbing the others.
It isn't a super-clean version of MVC, (especially when hooks get involved), but at a basic level it starts there.
And being proceedural about it isn't a bad thing IMO. A request from a website is pretty inherently proceedural: it is a process with a clear beginning and end, and just needs a procedure to process the request, get data, package it, then die. You can set up those steps with objects and object methods and OOP layouts (which would make some things easier) or you can just write alot of function calls and separate them out that way. Class members like private variables are lost that way but depending on the needs of the application... you might not care.
There is no one-grand-way to do development, and WP sits at like 20% of websites so it is doing something right. Probably something to do with not making people have to learn/memorize complex class hierarchies to get the database to answer the question 'what pages are child of page x?' and deal with that data. Could you make it that easy with OOP? yes, but if Joomla is any example of how hard it is to implement a complex custom website with OOP, then WP is FAR easier and quicker, and time is money.
As already mentioned in the comments, MVC is an architectural design pattern, not a specific framework, and no, Wordpress doesn't follow the MVC pattern.
There is a separation of views (templates) from the programming logic, but only in the frontend, not in the admin panel and a general separation of views and application logic is not inevitably MVC. An implementation of the MVC pattern usually assumes some kind of object oriented programming paradigm behind it and Wordpress is mainly implemented in a procedural way, with plain SQL queries in the PHP functions, therefore not having an actual model either.
One of the topics that periodically crops up in discussions as it relates to WordPress is the idea of WordPress and MVC.
But the thing is that MVC is not the silver bullet of web development that we try to make it out to be. Yes, it’s an awesome design pattern, and I personally think that it fits the web application model like a glove, but not every framework or platform implements that design pattern.
Case in point: WordPress is not MVC.
And that’s okay. I think we need to leave the desire of trying to shoehorn it into our projects aside especially when the pattern WordPress provides is not only sufficient, but works well when leveraged correctly.
“But I Love MVC!”
So do I! In fact, I spent the last year working on a project that more-or-less mimicked the MVC architecture.
A high-level example of MVC.
A high-level example of MVC.
For example:
Views were implemented using templates
Controllers were implemented by a combination of using function names like create, read, update, destroy, delete, and so on (even though these functions were hooked into the WordPress API
Models were functions also were called to validate and verify data prior to serializing the data. Again, this required that certain functions be hooked into WordPress to achieve the desired result.
Finally, a set of rewrite rules gave the application a clean set of predictable URLs in the format of /people/update/1 or /people/all.
What Pattern Does WordPress Implement?
WordPress implements the event-driven architecture (of which there are several variations such as the Observer Pattern).
In short, you can conceptually think of this as the following:
Things happen when WordPress is processing information.
You can register your own function to fire when these things happen.
Not too complicated, is it?
A high-level example of event-driven patterns
A high-level example of event-driven patterns
When you begin to think in terms of the paradigm in which it works rather than trying to make it work the way that you want it to work, it’s liberating. It helps to solve problems much more easily.
The bottom line is this: WordPress implements the event-driven design pattern, so even if you end up trying to implement MVC, you’re still going to have to utilize the hook system.
If you’re not careful, you can end up trying to craft the perfect architecture without actually getting your work done, and thus end up finding yourself so high up in the atmosphere of software that you’ve effectively become an architecture astronaut.
So You’re Saying Avoid Design Patterns?
Not at all! Design Patterns serve a purpose because, above all else, they basically give us solutions to previously and commonly solved problems. Use them!
But the point I’m trying to make is that we don’t need to try to force things to fit pattern just because we like the pattern. That’s not their purpose. Instead, leverage the primary pattern that your platform of choice implements – in our case, it’s an event-driven pattern – and then implement patterns where they fit (such as dependency injection or something like that).
Otherwise, it’s like trying to put your foot in a glove.
Courtesy (and totally copied :P) from : http://tommcfarlin.com/wordpress-and-mvc/
Just to update this with more recent information for people hitting this from search engines - the wp-mvc plugin http://wordpress.org/extend/plugins/wp-mvc/ goes a long way to creating a mvc framework for plugin development. You can find out more here: http://wpmvc.org/documentation/70/tutorial/
Just to add to the list of options, (I'm admittedly biased as the author,) swpMVC is a fully featured, lightweight MVC framework, inspired by Rails, Sinatra, Express, and FuelPHP. It's thoroughly documented, and while I have used and enjoyed wp-mvc, I wanted something where the models were able to populate views themselves, including form controls for interacting with said models.
I put this together largely to reduce the amount of controller code required to put together an app on top of WordPress, and the result is a very fast and effective framework that runs inside WordPress. The models are based on PHP Activerecord and 8 models are included for existing WordPress data types, including Post, PostMeta, User, UserMeta, Term, and a few more. Modeling data is very easy thanks to the activerecord library, and I've enjoyed working with this framework immensely thus far.
Also ships with underscore PHP and PHP Quick Profiler (as seen in FuelPHP.)
RokkoMVC is a micro MVC framework built especially for WordPress. The project is meant to simplify AJAX functionality in WordPress applications, as well as bringing in all the other benefits of using models, views, and controllers to your theme.
I had a bash recently at creating a plugin that makes use of a simple view-controller system, and quite liked the results, so I separated the template stuff out to its own repo. It offers object-based controllers, passing variables locally to PHP templates, template fragments (templates within templates) and components (template fragments with their own sub-controller). All in two tiny classes!
Of course, I wrote this code thinking that no other WP developer had considered the problem before ;-).
It's far from mvc, there is no kinda-sorta thing like some people say, it's either MVC or not... The fact that you write logic on the view level doesn't qualify it as a mvc framework. The reason people use it - it's easy to learn, you don't need to be hardcore php programmer, they're lazy.
Related
I am new guy to Demandware and I am switching from Magento to Demandware.
Demandware is not opensource I am not getting proper tutorials, stuff to understand the concepts of it.
I am from Magento so I know the Magento MVC structure.
But in Demandware we have different concepts like pipelines, pipelets, ISML scripts, ECMA script, DW scripts etc.
I want to know the MVC pattern of Demandware.
How it works and what are the basic concept I need to concentrate?
I would suggest to request a Demandware XChange account as soon as possible for you, so that you get access to the Demandware community portal and also to the API documentation.
In short:
Models are Demandware Forms and Demandware API objects
Controllers are Demandware Pipelines (there are JavaScript Controllers that are recently released, you may find these easier to understand if you have Node.js experience). These can call DW Scripts (DemandwareScript is based on ECMAScript standard 5.0 for JavaScript with some extensions like E4X and optional types)
Views are the isml templates. You should avoid including a lot of logic in them, either with isml tags like isif, isloop, etc. or with isscript.
Any further questions - let me know.
Hope this helps,
Zlatin
I hope you'll be able to avoid pipelines and dwscript. Those are a bit older. The most recent version works with plain old JavaScript, with pipelines being replaced by controllers.
Be aware that the underlying JavaScript engine is Rhino, which isn't really modern.
The Demandware documentation is open source now anyone can access to without having an exchange account it has the latest SFRA(javascript) based concepts as well
here is the link for the docs
Demadware Documentation
Demandware is very much designed around the MVC concept (in theory). The pipelines are basically your controllers and each pipeline filename (the xml file) is the first part of the URL and the start nodes inside the pipeline are the second part of the URL that basically represent the controller (eg Cart.xml has a start node called Show, so the url is Cart-Show). At the end of the pipeline flow chart is, usually, an interaction node to that links to an ISML file, those are basically the View and are HTML with some minor Demandware-specific markup.
Typically in the MVC world you try to prevent putting business logic in the views, however if you use SiteGenesis as your starting point you'll find that not to be the case on most of the pages. If you switch to using Javascript Controllers instead of Pipelines, then it'll be closer to the Magento style of MVC (but using NodeJS-like syntax).
I'm working on a wordpress plugin that takes the whole page and is about planing a trip.
The plugin spread out and contains several modules and more than 10 "views" (Booking, Billing, Register, My Profile, My Bookings, My comments, etc.).
I have a strong OOP and MVC background but this plugin was originally created on a single template with everything loaded with ajax and not in a organized way :)
What is good practice for organizing big plugins (semi small sites) in wordpress?
Is there a way to create direct links for the modules view files? something like:
domain.com/blog/wp/plugins/my_plugin/profile.php
Bounty:
I'm looking for guidelines here from people with experience.
Firstly, it's not easy to do, and it's harder to stick to as development progresses.
I'll try to answer your bullet points first, then try to talk about some architecture stuff I try to adhere to.
I organize them as close to normal as possible. So I usually end up with folders for Models, Controllers, Views. Try to write your application as much as possible in the same manner you would for anything else.
Use plugin_url().
If you're working on a project that won't be distributed (i.e. not a publicly released plugin), you've got some advantages because you can load in outside packages from Composer without worrying about conflicts from other places. So wherever possible, I'd advise offloading stuff to Composer.
I'm not a fan of how PHP implemented Namespaces, but I'm a huge fan of using them in conjunction with autoloading. You'll definitely make things easier on yourself if you use some form of Autoloading, even if it's not used with Namespaces.
Since WordPress works off of functional hooks, unless you (over?)engineer a lot of stuff, you're always going to end up with a bunch of hooks all over the place. Generally, my advice there is to try and keep those together in a file, and to never put hooks inside classes, especially constructors. Keep stuff in logical groups.
The trick really is to minimize the number of points where you're actually interacting with WordPress, and everywhere else to essentially write your code as you normally would, with decent design patterns and the like. You'll have to have certain points of contact (like the hooks and such) where you'll probably find yourself making some concessions to WordPress, but even there you can mitigate it by loading object methods as hook callbacks, and using those as jumping-off points to a "normal" application.
I've been interested in this problem for a while. I've got a couple ongoing projects in this area. One thing I threw together was for interfacing with GravityForms, and it's on github. It's really not complicated, but it might help explain some of how I've got about solving the problem.
I'm running out of specifics to add, but please feel free to drop me a line if you like. As I said, I'm really interested in solving this problem, and I think that if WordPress lasts and continues to be as popular as it is today, we'll have better solutions coming around.
I hope this is helpful!
EDIT: A more concrete example
I'll point some stuff out in the code I shared originally. It's sort of specialized, but you can use the principles for any hook-based functionality. As you can see here, I'm invoking a method of class GravityFormsHooks\Loader to handle hooking into objects. In GravityFormsHooks\Loader, I'm calling another static method on that class to actually execute the hook. This example will take either an action or filter, but it's tailored to Gravityforms specifically, so YMMV.
Essentially what this GravityFormsHooks\Loader::hook() method does is instantiate the class we're hooking into, and generate the hook as normal.
The class I'm calling from the main plugin file is GravityFormsHooks\Forms\Form. Note that any method you hook onto MUST be declared as public. If we're going to shoehorn ourselves into an MVC paradigm, this method here would be your controller. From there, you can jump off to injecting models, a template engine, all manner of cool stuff.
As I mentioned in my original post, I try to keep my points of contact with WordPress to an absolute minimum. I don't mean that you should write APIs doing stuff WordPress already has APIs for, just that your hooks should be centralized and minimized. It really is a useful separation of concerns, and as your application grows it'll help you to manage the complexity a lot more easily.
The examples I provided should work pretty well as a Hook Controller, with minimum modifications to remove some of the more specialized GravityForms stuff.
Let me know if you've got any other questions.
Considering the most popular MVC/MVVM client-side patterns (like Knockout.js, Angular.js, Ember.js, and others), I have one great doubt:
Also considering the modeling redundance in both sides, what is the advantages and disvantages to use those client-side patterns with MVC server-side patterns?
I struggled with how to answer this question... hopefully this helps, even if it is in a round-about way.
While some of the pros/cons have already been stated, I think the best rundown is in this answer.
For me, the biggest advantage to using client-side logic is the rich UI aspect.
But the key part of your question seems to be "model redundancy" (I'd call it duplicated logic, or at least having potential for duplicated logic). In my opinion, that is a problem which may exist independently of the pros/cons in the previous link.
So first of all, I think that the decision of whether or not to use a client-side framework should be made based on the well-documented pros and cons. Once that decision is made, the associated problems can be solved.
Lets assume you are using some sort of server-side framework/platform, as well as a client-side framework to provide a little bit of UI interactivity. Now there is a problem with where to put the model logic: on the client, server, or both.
One way to solve the problem is to define your model logic in only the client or the server. Then you have no code duplication, but it affects some of the higher-level pros/cons.
For example, if your model logic is 100% server-side, you lose some of the interactive part of the UI. Or, you are constantly throwing the model to/from the server, which will have a few cons.
If your model logic is 100% client-side, you could suffer performance problems, depending on the size of your view / model. This is one of the reasons Twitter is moving to a server-side processing model.
Then there is "both"... having model logic exist in both the client and the server. I think this is the best solution, as long as no logic is duplicated.
For example, on a shopping cart page, you may recalculate the cost of an order based on the price of a product, and a user-editable quantity box. I think this logic should only exist on the client. Other model properties that do not change once loaded are probably fine hosted on the server.
There's a lot of gray area here... I struggle with putting all the eggs in one basket. For example, choosing a client-side framework, creating a lot of client-side logic, and then [hypothetically] running into problems with performance, browser support, or something like that. Now you may want to tweak a page or two for performance (like move it server-side, a la Twitter). But I think being smart about how you structure your code will help mitigate that issue. If your code is maintainable and clean, moving logic from client to server won't be difficult.
The advantage is that the client side patterns are applicable at the client where the server has no direct reach. If you're building a rich, interactive HTML UI then use client side MVVM. Server side MVC may still be relevant in that case for delivering appropriate content to the client. For example, the ASP.NET WebAPI is a framework for creating HTTP APIs which has a similar controller architecture to the ASP.NET MVC framework. The API implemented with this framework may be called by client side code resulting in MVC on the server side and MVVM on the client side. Normally, when using MVC server side and MVVM client side, the responsibilities of the respective sides are very different and thus there is no redundancy.
The fact you an incorporate a MVVM model into an already implemented MVC framework is also a great thing, we recently added knockout to some new project pages to fit with in an already outdated MVC framework (old pages, not the framework itself).
I think MVVM is fantastic as the above answer states it provides an exceptional user experience with extremely fast response times, you can hide your validation calls in the backround with out slowing them down and its intuitive.
The pain however is that it is VERY hard to unit test and you can get some extremely LARGE javascript files, also the extra coding we've had to do as our legacy systems still run on IE6 is ridiculous.
But MVVM and MVC don't have to be used exclusively on there own, we use both. But having 3 levels of validation is something that still bugs me.
advantages
This can rock.
disvantages
You can screw it.
Seriously. Making use of transporting part of the frontend logic into the browser can boost your application development why you keep more strict data-processing encapsulated on server-side.
This is basically layering. Two layers, the one above talks with the one below and vice-versa:
[client] <--> [server]
You normally exchange value objects in a lightweight serialization format like Json between the two.
This can fairly well map what users expect in a useful structure while domain objects on server-side could not be that detailed.
However, the real power will be if the server-side is not in written in javascript at some certain point because I think you can not create well domain objects there. Consider Scala (or something similar expressive) then if you run into that issue.
Ten months later after this question, I have used the both patterns inside the same application.
The only problem was the need to map the models twice.
MVC (ASP.NET MVC 4 Web API)
The most important resource was the routes.
Models were created to database interactions and as arguments for
controllers' actions.
Controllers were created to manipulate the API
requisitions and to render the views.
Views were not modeled with
server-side models, but all the resources of Partial Views and
Sections.
MVVM (Knockout.js)
Models were created with the same properties as the server-side models.
Views were binded with models' properties, and decreased a lot of the views' size.
View-models were created with the values provided from API methods.
Overall, the MVC combination with MVVM were very useful, but it needed a big expertise and knowledge. Patience is required too, because you need to think about the responsibilites of each application layer.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I realise this might be a little vague but I honestly don't know where else to ask. I have some history with PHP and I am trying to teach myself ASP.NET MVC3.
While I can find a LOT of source material on syntax and tutorials on various parts. I've started it off and I've got quite a bit going but I'm finding it a bit difficult to figure out exactly how to design the whole thing with regards to where to put things and I'm not entirely certain who I can ask or where I can find these things out?
The project I'm working on, in an attempt to teach myself is a form of online rpg game site. I've got user registration and log in, I wrote a custom membership provider to fit that to my existing database structure. But the trouble I'm having knowing where to do database lookups and how to store data etc. For example, let's say you log in, you have a certain amount of gold. On the right side of the status bar on the _layout page it will always display this value. Where do you look this up? How do you remember it? In the controller? Which controller? Etc etc.
Can anyone maybe recommend either a good set of advanced tutorials or some kind of forum where this can be discussed?
Thanks!
I learned everything i know from:
Getting Started with ASP.NET MVC 3
ScottGu's Blog -> awesome blog entries on mvc 3
Must see the Music Store Tutorial App
Check out a great book by Steve Sanderson - Ive used the previous two editions to get me upto speed with MVC.
Pro ASP.NET MVC 3
If your looking to use Entity Framework then I can also recommend;
Programming Entity Framework
The MSDN and ASP.NET sites have a LOT to offer on MVC3. I would also suggest buying the two MVC3 books by Phil Haack and Steve Sanderson.
http://www.asp.net/mvc/tutorials/getting-started-with-aspnet-mvc3
http://www.asp.net/mvc/tutorials/overview/creating-a-mvc-3-application-with-razor-and-unobtrusive-javascript
http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application
http://msdn.microsoft.com/en-us/library/gg416514%28v=vs.98%29.aspx
http://weblogs.asp.net/jgalloway/archive/2011/03/17/asp-net-mvc-3-roundup-of-tutorials-videos-labs-and-other-assorted-training-materials.aspx
Those are all good links and tutorials. In addition, you are going to want to have a separate database for your data vs. your Authentication and Authorization. This will allow decoupling and better security. You should be storing data in a database, and then the model will hold access to that database through a DAL (Data Access Layer) usually with the controller holding an instantiated repository of the DAL. In this sense the controller can build objects from the model (and thereby from the database) and then send them to the view through strongly typed objects for you to use in a User Interface.
Nerd Dinner is a pretty good sample of the whole picture, you can download the sample code and play with it.
http://nerddinner.codeplex.com/
The problem I find is a lot of examples don't use best practices for MVC in favour of simplicity and ease of reading in tutorials. So I'll outline some of the things I've found out the hard way and that work for me.
Personally from what I've found is your controller should be responsible for handling information via ViewModels to act as Data Transfer Objects (DTOs) between your business logic and your views, and that's all they should have in them. I choose to never have business logic in the controller and instead opt for a series of service classes designed to deal with their own group of responsibilities (IoC takes care of most concerns the Services may have).
This is done to keep the business logic DRY and to make it easier should you decide to try making a mobile version of your site later, or maybe expose a public WebService/API to your data.
The views should each use ViewModels specifically meant for each view, and these views should ONLY consist of primitive types or other view models. Never use a data entity from your ORM directly, though I'll be honest I have been known to break my own rule on this when it comes to views that only display information, but I usually pay for it later. Validation rules imposed on your data model are not necessarily applicable to a form and data loaded on your entity may not be relevant to your view either. ORM's that support Lazy Loading complex data entities can cause havoc with some VERY useful 3rd party libraries you can use in MVC like MiniProfiler and Glimpse, not to mention other issues when it comes to rendering these objects in forms for posting back later. So try to stick to flat ViewModels if possible.
I typically name my ViewModels according to their use. so my Register page may use a model called AccountsRegisterViewModel. However when I postback I usually use a different model called AccountsRegisterFormModel. This is because many times there is information I need to pass to render in the view but I really don't care about it (nor will it be present in most cases) on the action that accepts my postback. Also, MVC requires you to disambiguate your actions that use the same name via different parameters so using different view models helps there. For example CreateAccount() to show the account creation page and CreateAccount() that accepts your submission from the form. Though you can explicitly change where each form posts, the main focus with MVC is convention over configuration so I try not to change where forms post back to.
For your specific example of showing relevant information (Gold balance) you're likely going to want to create a Child Action with it's own view that would be responsible for doing it's own data access, or if you want to try your hand at ajax, have the balance be something handled in a smiple partial view that makes a call to a public action that returns JSON.
Those are the practices I've found have worked for me so far.
VS2010 Pro + SqlServer Express.
Having been dropped into ASP.NET MVC 3 with no guidance but the web (2 books on order), I can't even get off the ground.
The MVC itself I get. Not a problem.
PHP, Ruby, and even ghastly WebForms firmly tucked into my toolbelt, with a long history of C++ QT client-server development before that.
Tying ASP.NET MVC 3 to a database using EF4 ORM is killing me.
The goals:
Use database modeled by DBA. I can specify all naming conventions, but code first is not an option!
Import to EDMX. This will be regularly updated using VS tools from the DBA's DB, never edited directly.
Generate partial classes from EDMX, for use as model. This will regularly be updated using VS tools, never edited directly.
Use 'buddy' to extend above model class with code as the Controllers/Views need.
Intuitively use the resulting model, pass it to the view, retrieve posts into it for insert/save, etc...
I've seen and read so many blogs, forum posts, walkthroughs, and stack overflow posts regarding this very use case.
I even tried riding the magic unicorn, followed by the latest 4.2beta1 with DbContext generators.
But can't get off the ground.
I follow instructions, but just not understanding how to do anything with it.
What conventions does the 'buddy' require (if any)? How do I use it? How do I get data with it? How do I write data?
Every example looks different. MVC guides are always focused on the UI side. EF guides don't cover usage in the MVC.
These are basic questions, and I'm feeling like the most incompetent idiot in the WWW right now.
Is anyone out there currently using MVC3 & EF4.x in the way I describe above?
This video is a good starting resource. Its a video of a guy creating an app from scratch that uses entity and a sql database (though he makes the db in the video, its still good for seeing some basics in action). You can see how he pulls data from the database, displays it on the page, and saves changes back to the database.
The first question I would ask is why are you stuck on using EF as an ORM or even insisting an ORM at all? I'd choose tools to suit the job here, especially given the constraints of the data layer.
Buddy classes were a concept invented in a day when the main .NET ORMs had no code-first option as ORM-encumbered class instances really don't behave well under things like model binding. Nevermind you could not decorate them with the DataAnnotations one used to indicate fields were required. Typically, the technical requirement is to use [MetadataType] attributes to tie your buddies to your models and perhaps something like AutoMapper to map data to and fro.
All that said, as a guy who has a few apps with lots of buddies and lots of automapping going on, you might want to think otherwise -- it is a bit of a maintenance nightmare. I'm living it.
There are some really good getting-started videos and tutorials right on ASP.NET MVC's site. The "Model (Data)" section is Entity Framework focused and touches on hot/trending topics like Repositories and Units Of Work.