I’ve spent quite a few years working with MVC architectures, but of course many architectures employ a model-oriented approach to developing software systems. There are many great reasons to do this especially if you’re looking to port your system or re-use the models of your existing system elsewhere. You may often get told that there are no plans to port the system, or to re-use the existing models for other purposes (some derivations of the system perhaps). Either way it doesn’t matter, it’s good practice to keep your models as close to the actual representation of the entity/object - or whatever you want to call it -as possible.
There will be times when you need to extend your models somewhat for domain-specific reasons. Let’s say for example you had a model, “City” which had an attribute of “Population” and you’re asked a question; “what constitutes a small, medium and large city?” The thing with this is dependent upon the context in some instances, so in one system it may be small and yet in another it could be large for the same population group. Don’t ask me why this happens, it just happens. Of course there’s many approaches to domain-dependent properties like this, some are database-driven, others are stored by text in XML configuration files, and others are compiled into the source code. Our system may depend upon these specifications so we need a way to keep our models as realistic as possible without tarnishing their correctness. There’s a few methods to doing this, and it will also depend upon your environment/tools available through your language. As I spend 95% of my time working in C# then you’ll find these examples quite specific to C#.
Okay I’ll admit it, I’ve never actually done this, but it’s an idea I had the other day. A derivation of the model is technically a specialisation, so I couldn’t see any reason why this wouldn’t be valid (until proven to me otherwise). Let’s again take the example of a model called “City”. If we wanted a property called “PopulationGroup” on it then we could do something like the following:
gist id=1039578
This way the parent class doesn’t get littered with unnecessary properties that won’t be used in other systems. Of course by strict OO principle it means that this subclass is a specialisation of its parent, which to some degree is true because it’s specialised for the context it is set in. I’d love to hear feedback on this first point.
Supposedly evil, yet they’ve proved useful to many over the years for .NET. The concept is very similar to the last one except you’re not extending, the final built code is a combination of all the partial classes (as long as they’re in the same namespace I believe). So, much like before, you get the following.
gist id=1039581
The benefit being that it’s not a specialisation, yet the code is separated out enough that if you were to port the original models then you could without them being littered with these domain-specific methods.
Again these are specific to .NET I believe, but once again they separate out the domain-specific code for them to be viably used. Instead, you’d get something like the following:
gist id=1050675
Extension methods are used all over the place it seems, one reason for this is that you can extend the core language API’s functionality using them which is particularly useful dependant on how you feel about defining your own functionality on top of pre-build API’s.
When I say helpers, I don’t mean those domain-specific ones which are used in views, I just mean in general helpers which you can pass data and a value being returned. In the previous example we could instead pass just the value to a helper which would return what we want. I always find these are too decoupled from the original code, however. They would make no sense outside of the context of the domain, hence why I believe one of the previous methods makes more sense. Plus, it encourages code to be managed in an untidy manner in my opinion causing lots of code-crumbs (code that gets left behind once something has been removed from the system). Very simply we’d have something that looks like the following:
gist id=1050678
It sure looks very clean, but there is such thing as being a clean freak which can have its drawbacks in these examples.
There’s a lot of varying opinions out there. After talking to some people in the industry I found that they tightly integrated their models with DAL which seemed odd to me, but only because I’m used to writing systems with portable models in the event that it does need to be used elsewhere, or we are to change the underlying DAL architecture. Sure, it’s like preparing for nuclear attack in a peaceful country but when it only requires a few minutes more work then the time-cost benefit is quite great. Furthering this, you can obviously identify what’s part of the core system and what lay on the outer edges. This can be important during database development not to confuse higher-level model features with what should and shouldn’t be stored in the database. Quite often application-level derivations of model data can be hugely beneficial, especially considering the computation overhead being so low, and process of managing your data being so much easier.
I haven’t got it perfect by any means, and there’s a fine balance that’s dependant upon your application. I don’t believe it’s a general rule but you should take into consideration the bigger picture when it comes to your application. For example, if another developer came along and wanted to look at a class that contains just the model information, yet held within it is a monstrosity of DAL, model data, and helpers then it makes life more difficult for newly introduced programmers, or generally others trying to manage your code.
blog comments powered by Disqus