ASP.NET MVC Auto generate integer number

asp.net asp.net-mvc entity-framework entity-framework-4 entity-framework-6

Question

Good day, a really newbie developer here.

I Have a form and it have a entity of "QueueNumber" Can someone show me how to code so that when ever i save my form it generates automatically QueueNumber + the Prefix, btw my prefix entity is in another class

public class Queue
{
    public int QueueId { get; set; }
    [Required]
    public string Name { get; set; }
    public string QueueNumber

    public int ServiceId { get; set; }

    public Service Service { get; set; }
}

-

public class Service
{
    public int ServiceId { get; set; }

    [Display(Name = "Service Name")]
    public string ServiceName { get; set; }

    [Display(Name = "Service Letter")]
    public string ServiceLetter { get; set; }

    [Display(Name = "Status")]
    public bool? Status { get; set; }

    [Display(Name = "Assigned Location")]
    public int? LocationId { get; set; }


    public virtual Location Location { get; set; }
    public virtual ICollection<Customer> Customer { get; set; }
}

Outcome in database : 1. A001 2. A002 3. A003

i just want to be able to generate a queue number automatically and when i save in data base its like A= Service Letter and 001=QueueNumber. Thankyou

1
0
3/6/2019 7:19:34 AM

Popular Answer

If the QueueNumber needs to be persisted to the table, then I would set it up as a calculated column so that the database can manage computing it and updating it if the underlying fields change.

If it is just something that you want to represent in the UI then I would recommend having the view model calculate this.

The entity can calculate something like this with a [NotMapped] attribute. For example:

public class Queue
{
    public int QueueId { get; set; }
    [Required]
    public string Name { get; set; }

    [NotMapped]
    public string QueueNumber
    {
        get { return string.Format("{0}{1:000}", Service?.ServiceLetter ?? "?", QueueId); 
    } 
    [ForeignKey("Service")]
    public int ServiceId { get; set; }
    public Service Service { get; set; }
}

The problem with this approach is that to be able to rely on your Queue to reveal a QueueNumber, the Queue must eager load the Service, or you enable lazy loading and risk that performance hit vs. having Service == #null and getting an exception or invalid QueueNumber result. In the above example, if the Service isn't eager loaded you will get back something like "?001".

I prefer to use ViewModels for a number of reasons including performance, security, and handling conditions like this more cleanly.

For example, given a QueueViewModel as such:

[Serializable]
public sealed class QueueViewModel 
{
    public int QueueId{ get; set; }
    public string Name { get; set; }
    public string ServiceName { get; set; }
    public string ServiceLetter { get; set; }
    public string QueueNumber 
    {
        return string.Format("{0}{1:000}", ServiceLetter, QueueId);
    }
}

Then when reading the data, we don't pass Entities to the view, we pass our view model...

var viewModel = context.Queues
    .Where(x => x.QueueId == queueId)
    .Select(x => new QueueViewModel
    {
        QueueId = x.QueueId,
        Name = x.Name,
        ServiceName = x.Service.Name,
        ServiceLetter = x.Service.ServiceLetter
    }).Single();
return viewModel;

The benefits of this approach:

  1. We don't have to worry about eager/lazy loading. The query fetches everything needed, and our view model can compute anything needed from the data loaded. (Queries can compute values as well if you like, but be wary of limitations in that the query has to be able to go to SQL, so no user functions, etc.)

  2. Performance is improved since the query only returns the data needed rather than entire entity graphs, and no rish of lazy load hits.

  3. Security is improved, we expose no more data to the client than is expected/needed, and we don't open the door for "lazy" updates where entities are attached to a context and saved without proper validation.

0
3/6/2019 4:12:23 AM


Related Questions





Related

Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow