Reputation: 31
I'm hoping this is straight forward. I'm trying to implement the Command Pattern in my MVC application I'm making. The only issue I'm seeing is that the number of Command objects is really high.
I have 11 tables each with around 20 fields that need to be updated.
My question is do I need to have a different object for each field?
This is a healthcare application, so let me give an example. I have a table called KeyHospital, this table stores Hospital information and only Hospital information for our Hospital Clients. I've used Linq to SQL for my connection to the database. The KeyHospital table is probably the largest as far as fields go. What I've done is create a new object per field.
public class ChangeHospitalDEA : ICommand
{
public ChangeHospitalDEA(int id, string newDEA)
{
var Thishospital = (from Hospital in _context.Keyhospitals
where Hospital.ID == id
select Hospital).Single();
Thishospital.DEAnum = newDEA;
}
}
I have ICommand as an abstract class.
public abstract class ICommand
{
public AllkeysDataContext _context = new AllkeysDataContext();
public void Execute()
{
_context.SubmitChanges();
}
}
Am I doing this correct? I just feel like I'm writing lots of code for this and it's one of my first times using the Command Pattern.
Upvotes: 2
Views: 885
Reputation: 2662
This is might not be what you want to hear but I would restructure your user interface to be Tasks based UI and construct your UI into common Tasks for example Change Drug Enforcement Administration number and these tasks can be refined over time.
If you have existing analytics you will notice that certain field will be only changed together and these could be logically grouped into common tasks I also feel that is it is a bad practice to hide database calls within constructors and would move that linq statement to the Execute method and have the ctor only initialise public properties or private fields and have them field being used within the execute method.
Major reason for moving the query into the execute method is to reduce the time the chances of any Optimistic concurrency errors.
Also I also feel that calling the Base class ICommand is not a good practice and may lead to confusion in the future and would recommend you calling it CommandBase or changing it to an interface once again.
Upvotes: 0
Reputation: 34663
Considerably too granular. Instead, you should define commands for actions such as inserting a new entity, (graph of one or more related objects) updating an entity, etc.
A command would be used whenever you want to perform an action. In some cases changing a single field may constitute an action, such as returning additional data, or providing suggestions. Such as an AJAX call to validate an entered address. Also, ICommand
is a poor name choice for a base abstract class. ICommand
is a common interface for command architectures. (the "I" prefix is conventionally reserved for interface names.) I deal predominantly with MVVM but I would suspect that MVC has a common command interface already.
Upvotes: 1