3

I have an assembly generated using POCO template using Entity Framework (e.g. "Company.Models.dll").Besides generated POCOs I also have "follow up" partial classes that define meta data using System.ComponentModel.DataAnnotations. So for example Company.Models.Customer is auto-generated (in separate folder) and then I have partial class with same namespace. Within this partial class I define inner class for metadata...For example:

using System.ComponentModel;
using System.ComponentModel.DataAnnotations;

namespace Company.Models
{
    [MetadataType(typeof (CustomerMetaData))]
    public partial class Customer
    {
        public override string ToString()
        {
            return String.Format("Id: {0}, Name: {1}", Id, Name);
        }

        //[Bind(Exclude = "Id")]
        public class CustomerMetaData
        {
            [ScaffoldColumn(false)]
            public int Id { get; set; }

            [DisplayName("Name")]
            [Required(ErrorMessage = "Customer Name is required.")]
            [StringLength(100, ErrorMessage = "Customer name cannot exceed 100 characters.", MinimumLength = 2)]
            public string Name { get; set; }
        }
    }
}

The issue I am having is that I now want to use this assembly in my MVC project and want to use MVC specific attributes (like the commented out Bind attribute above).However, doing so requires making my Company.Models.dll dependent on System.Web.Mvc.dll.

I would like to avoid this at all costs if possible but how?

So far I am aware of 2 possible solutions and am asking community for their opinions or better approaches...

Solution 1

This solution has been discussed here: Using Data Annotations on POCO's with MVC for Remote Validation The "trick" was to use ViewModels and map (either mannually or using AutoMapper) POCOs to MVC project specific ViewModels. Then apply all necessary attributes to ViewModels instead of domain model POCOs. While this makes sense for large projects it is a bit overkill for small simple solutions...

Solution 2

Use Bind attribute in Controller action parameters (as seen on some http://www.asp.net/mvc tutorials). For example:

//
// POST: /Customer/Create
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create([Bind(Exclude="Id")]Customer customerToCreate)
{
        if (!ModelState.IsValid)
        return View();

        // TODO: Add insert logic here
    return RedirectToAction("Index");
    }

Using this solution would allow to skip dependency on System.Web.Mvc from my POCO dll at the cost of having to remember to insert Bind attribute on all relevant Controller actions. Also, if I have multiple ASP.NET MVC projects the issue gets worse...

So, is there another way? ;)

Community
  • 1
  • 1
zam6ak
  • 7,229
  • 11
  • 46
  • 84
  • Is seems like the Solution #1 is preferable way of doing this even for simple projects (for which it can be claimed it is overkill). Although both answers, from David Neale and Chuck Conway, are very good, the one from David Neale seems so reaffirm the approach (solution 1) so I am marking his answer as accepted. – zam6ak Dec 06 '10 at 14:23

3 Answers3

2

I'd suggest that your POCO entities do not contain any UI-specific code. Ideally they wouldn't contain any code specific to data persistence either but EF makes this tricky.

The first solution is definitely best solution to use in order to make your application more scalable and to better separate out your concerns.

Another solution could be to create your own domain attributes (MyRequiredAttribute, MyStringLengthAttribute etc.) and place these in your core assembly. You could then create a custom metadata provider to have MVC recognise these attributes. Here's an example of how to create this: http://bradwilson.typepad.com/blog/2009/10/enterprise-library-validation-example-for-aspnet-mvc-2.html

David Neale
  • 16,498
  • 6
  • 59
  • 85
  • I like the solution #1 myself also, but as I mentioned, sometimes its just overkill in simple ASP.NET MVC projects (especially when your form and the model are 1:1, meaning you don't need mapping). Of course, there are number of discussions on the net specifying that model should never be directly exposed to the view anyway, but that is a "horse of a different color" – zam6ak Nov 30 '10 at 18:52
  • I agree, a POCO should stay exactly that... Plain Vanilla properties without all the UI attributes. – Charlie Brown Nov 30 '10 at 19:28
  • @Charlie - plus domain-specific behaviours if you're following DDD. – David Neale Nov 30 '10 at 20:13
  • I would agree with @David Neale here in regards to DDD. In general, I think extending and creating specific domain attributes is OK (the POCO assembly would still not require additional dependencies) but there is no easy way (to my knowledge) getting away from MVC if you want Bind attribute usage. – zam6ak Nov 30 '10 at 21:14
  • 1
    No, I'd agree. However, I'd say that using your domain entity to control persistence logic, validation logic, view logic and potentially business logic is a huge amount of cross-cutting concerns already - if your application is too small to warrant separating that out then I'd suggest a reference to the MVC assembly shouldn't be too much of an issue. – David Neale Nov 30 '10 at 23:29
0

A third option, which is similar to solution 2, is binding to the customer type.

You would create a Model Binder.

Watch Jimmy Bogards MVC Conf presentation on the subject: http://www.viddler.com/explore/mvcconf/videos/1/

Sample Code:

Global ASAX

    protected void Application_Start()
    {

        ModelBinders.Binders.Add(typeof(Media), new MediaModelBinder());
        ModelBinders.Binders.Add(typeof(Album), new AlbumModelBinder());

    }

ModelBinder Class

public class MediaModelBinder : BaseModelBinder, IModelBinder 
{
    /// <summary>
    /// Initializes a new instance of the <see cref="MediaModelBinder"/> class.
    /// </summary>
    public MediaModelBinder() : base(DependencyInjection.Resolve<IUserAuthorization>()) { }

    /// <summary>
    /// Binds the model to a value by using the specified controller context and binding context.
    /// </summary>
    /// <param name="controllerContext">The controller context.</param>
    /// <param name="bindingContext">The binding context.</param>
    /// <returns>The bound value.</returns>
    public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
    {
        var mediaRepository = DependencyInjection.Resolve<IMediaRepository>();
        User user = GetUser(controllerContext);

        int mediaId = Convert.ToInt32(controllerContext.RouteData.Values["id"]);
        Media media = mediaRepository.RetrieveByPrimaryKeyAndUserId(mediaId, user.Id);

        return media;
    }
}
Chuck Conway
  • 16,287
  • 11
  • 58
  • 101
  • Could you elaborate on what you meant by "each customer type"...Furthermore, that would still leave the issue when using the models assembly with multiple ASP.NET MVC projects wouldn't it? – zam6ak Nov 30 '10 at 18:31
  • It depends, are all your POCO shared across the MVC projects? You could create a class library where you put all common MVC code, the above code would go in this library. Then all you would need is to wire up the bindings in the Global.ASAX for each MVC application. – Chuck Conway Nov 30 '10 at 18:39
  • OK I just watched the video and it is very informative. However, the goal of mine is how to make this as simple as possible (if possible at all) for simple MVC projects. To answer your question, yes my POCO assembly would be shared by all MVC projects. Also, your example, if I am not mistaken, is case og "selecting and binding" not "updating/creating and binding" which is where Bind attribute would play a role - or am I mistaken? – zam6ak Nov 30 '10 at 21:10
  • @zam6ak I see your point. You should still be able to use the modelbinders to encapsulate your bind attributes. I'm just not sure on the syntax. – Chuck Conway Nov 30 '10 at 21:35
0

Easiest solution: put your Partial Class Customer in your MVC project. No other changes needed.

ZippyV
  • 12,540
  • 3
  • 37
  • 52
  • 1
    You can not have partial classes across projects: http://stackoverflow.com/questions/647385/is-it-possible-to-have-two-partial-classes-in-different-assemblies-represent-the – Chuck Conway Nov 30 '10 at 19:32
  • Thanks for the correction, I was planning to make that mistake. – ZippyV Nov 30 '10 at 19:45