How far is to far for separation of concerns?
-
I can't see that it will add any benefit. On the rare case that it does I have created a View model to handle it.
Without a tangible benefit what's the point? Work for the sake of work: over engineering an application doesn't make it better - more often that not it becomes a support nightmare. KISS: keep it simple, stupid is what I was always taught (and, yes, my name was 'stupid').
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
mark merrens wrote:
adding complexity because it is clever does not make it better
There speaks a true software engineer. :) It takes many years of banging out code to know that. Young guys, listen.
============================== Nothing to say.
Thanks. :thumbsup:
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
I currently working on a project in MVC .net and I found my self asking how far is to far for separation of concerns? A little back history. The project I am working on is separated into business logic, data access, and business entity layers. It is a web app that is developed using the MVC pattern so it also has Controllers and Views. We are currently using our business entity objects as our model for this project. But now one of the developers I work with wants to implement view models that inherit from the business entities. 99.9% of the time the view model will just be an empty class that inherits from the business entities. I am against using adding another layer to the app and I want to find out what some other peoples opinions are.
You should use a "View Model" when there are class members that have only to do with the view, such as whether or not some element should be displayed, its color, what have you. But in that case I would not inherit from the Business entity object, I would have a copy of the class that I translate back and forth to the entity object. If you're concerned with performance penalty, it really isn't a concern since the user-time and network usage will swamp any time taken to translate between the "View Model" and the "Business Model".
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun -
I currently working on a project in MVC .net and I found my self asking how far is to far for separation of concerns? A little back history. The project I am working on is separated into business logic, data access, and business entity layers. It is a web app that is developed using the MVC pattern so it also has Controllers and Views. We are currently using our business entity objects as our model for this project. But now one of the developers I work with wants to implement view models that inherit from the business entities. 99.9% of the time the view model will just be an empty class that inherits from the business entities. I am against using adding another layer to the app and I want to find out what some other peoples opinions are.
Add ViewModels as and when they are needed, not an instant before. Your junior developers will thank you for it, as will your boss for not spending a half-day writing code which has no inherent value. Mr. Merrens represents my feelings on this point very well. Allow me to add my own tuppence ha'penny; As an earnest, aspirational young dev, I spent many months poring over architecture books and learning new and obscure scripting languages, familiarising myself with the DLR etc., in the hope it would make me a better dev, and to an extent it did. But, better still was the realisation that 9/10 times, you don't need this stuff for LOB apps. The Gang of Four book is full of excellent patterns and paradigms. But, and this is a big but, most of them apply to software that does stuff you just don't find yourself doing, in the normal run of things. graphics processing, text editors, machine programming... Most LOB apps consist of a basic UI, some vanilla logic in the middle tier, and data access. That is all. It is THE most important thing to know what you don't need. And this isn't bitter-old-man stuff. Rather, it's bright-young-man-with-better-things-to-do stuff, is what it is. Use frameworks and patterns to remove the makework out of developing software, not to put it in. Data access and logging modules are things you should never, ever, have to write. Another very real way of looking at it is saying that you should reduce the amount of code you write to the bare minimum. That reduces the potential error footprint. Don't go around solving problems that don't exist. Rather, concentrate on the ones that do. :thumbsup: [Edit] Thanks for the 5 votes guys. But, Ahmed, dude? Get out more... :cool: I hasten to add that I have personal experience of making a project much more tiresome than it should have been because I went in guns hot with factory patterns and generics and doodads of every description. Never again. So, I guess, do as I say, not as I do... I have also spent the last two months rewriting a monstrous desktop app which does some very simple things in extremely complex ways, because three separate contractors came in with their own twatfaced opinions about what constituted a proper DAO layer. Ludicrous.
Smokie, this is not 'Nam. This is bowling. There are rules. http://melpadden.wordpress.com LinkedIn
-
Add ViewModels as and when they are needed, not an instant before. Your junior developers will thank you for it, as will your boss for not spending a half-day writing code which has no inherent value. Mr. Merrens represents my feelings on this point very well. Allow me to add my own tuppence ha'penny; As an earnest, aspirational young dev, I spent many months poring over architecture books and learning new and obscure scripting languages, familiarising myself with the DLR etc., in the hope it would make me a better dev, and to an extent it did. But, better still was the realisation that 9/10 times, you don't need this stuff for LOB apps. The Gang of Four book is full of excellent patterns and paradigms. But, and this is a big but, most of them apply to software that does stuff you just don't find yourself doing, in the normal run of things. graphics processing, text editors, machine programming... Most LOB apps consist of a basic UI, some vanilla logic in the middle tier, and data access. That is all. It is THE most important thing to know what you don't need. And this isn't bitter-old-man stuff. Rather, it's bright-young-man-with-better-things-to-do stuff, is what it is. Use frameworks and patterns to remove the makework out of developing software, not to put it in. Data access and logging modules are things you should never, ever, have to write. Another very real way of looking at it is saying that you should reduce the amount of code you write to the bare minimum. That reduces the potential error footprint. Don't go around solving problems that don't exist. Rather, concentrate on the ones that do. :thumbsup: [Edit] Thanks for the 5 votes guys. But, Ahmed, dude? Get out more... :cool: I hasten to add that I have personal experience of making a project much more tiresome than it should have been because I went in guns hot with factory patterns and generics and doodads of every description. Never again. So, I guess, do as I say, not as I do... I have also spent the last two months rewriting a monstrous desktop app which does some very simple things in extremely complex ways, because three separate contractors came in with their own twatfaced opinions about what constituted a proper DAO layer. Ludicrous.
Smokie, this is not 'Nam. This is bowling. There are rules. http://melpadden.wordpress.com LinkedIn
Mel Padden wrote:
Use frameworks and patterns to remove the makework out of developing software, not to put it in. Data access and logging modules are things you should never, ever, have to write. Another very real way of looking at it is saying that you should reduce the amount of code you write to the bare minimum. That reduces the potential error footprint.
Yes! Yes! Ohh! YES!
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun -
Add ViewModels as and when they are needed, not an instant before. Your junior developers will thank you for it, as will your boss for not spending a half-day writing code which has no inherent value. Mr. Merrens represents my feelings on this point very well. Allow me to add my own tuppence ha'penny; As an earnest, aspirational young dev, I spent many months poring over architecture books and learning new and obscure scripting languages, familiarising myself with the DLR etc., in the hope it would make me a better dev, and to an extent it did. But, better still was the realisation that 9/10 times, you don't need this stuff for LOB apps. The Gang of Four book is full of excellent patterns and paradigms. But, and this is a big but, most of them apply to software that does stuff you just don't find yourself doing, in the normal run of things. graphics processing, text editors, machine programming... Most LOB apps consist of a basic UI, some vanilla logic in the middle tier, and data access. That is all. It is THE most important thing to know what you don't need. And this isn't bitter-old-man stuff. Rather, it's bright-young-man-with-better-things-to-do stuff, is what it is. Use frameworks and patterns to remove the makework out of developing software, not to put it in. Data access and logging modules are things you should never, ever, have to write. Another very real way of looking at it is saying that you should reduce the amount of code you write to the bare minimum. That reduces the potential error footprint. Don't go around solving problems that don't exist. Rather, concentrate on the ones that do. :thumbsup: [Edit] Thanks for the 5 votes guys. But, Ahmed, dude? Get out more... :cool: I hasten to add that I have personal experience of making a project much more tiresome than it should have been because I went in guns hot with factory patterns and generics and doodads of every description. Never again. So, I guess, do as I say, not as I do... I have also spent the last two months rewriting a monstrous desktop app which does some very simple things in extremely complex ways, because three separate contractors came in with their own twatfaced opinions about what constituted a proper DAO layer. Ludicrous.
Smokie, this is not 'Nam. This is bowling. There are rules. http://melpadden.wordpress.com LinkedIn
Well said. :thumbsup:
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
I currently working on a project in MVC .net and I found my self asking how far is to far for separation of concerns? A little back history. The project I am working on is separated into business logic, data access, and business entity layers. It is a web app that is developed using the MVC pattern so it also has Controllers and Views. We are currently using our business entity objects as our model for this project. But now one of the developers I work with wants to implement view models that inherit from the business entities. 99.9% of the time the view model will just be an empty class that inherits from the business entities. I am against using adding another layer to the app and I want to find out what some other peoples opinions are.
Everyone else has gone over whether you need them or not. So I'll just add this: Please, for love of all that is Holy, if you do use view models, do not ever have them inherit from your business models. Madness lies that way. Have them encapsulate the business models you need, or copy the properties if more separation is needed, but don't ever inherit one layer from another. That completely defeats the purpose of layering in the first place.
-
I currently working on a project in MVC .net and I found my self asking how far is to far for separation of concerns? A little back history. The project I am working on is separated into business logic, data access, and business entity layers. It is a web app that is developed using the MVC pattern so it also has Controllers and Views. We are currently using our business entity objects as our model for this project. But now one of the developers I work with wants to implement view models that inherit from the business entities. 99.9% of the time the view model will just be an empty class that inherits from the business entities. I am against using adding another layer to the app and I want to find out what some other peoples opinions are.
-
How about you want to include in your model a list of objects and a list of countries for thr drop-down?
In that case I would create a view model for the business entity that needed the drop down or use ViewData. I am against creating view models for all of the business entities just so we can say we have a view model layer.
-
Everyone else has gone over whether you need them or not. So I'll just add this: Please, for love of all that is Holy, if you do use view models, do not ever have them inherit from your business models. Madness lies that way. Have them encapsulate the business models you need, or copy the properties if more separation is needed, but don't ever inherit one layer from another. That completely defeats the purpose of layering in the first place.
-
Add ViewModels as and when they are needed, not an instant before. Your junior developers will thank you for it, as will your boss for not spending a half-day writing code which has no inherent value. Mr. Merrens represents my feelings on this point very well. Allow me to add my own tuppence ha'penny; As an earnest, aspirational young dev, I spent many months poring over architecture books and learning new and obscure scripting languages, familiarising myself with the DLR etc., in the hope it would make me a better dev, and to an extent it did. But, better still was the realisation that 9/10 times, you don't need this stuff for LOB apps. The Gang of Four book is full of excellent patterns and paradigms. But, and this is a big but, most of them apply to software that does stuff you just don't find yourself doing, in the normal run of things. graphics processing, text editors, machine programming... Most LOB apps consist of a basic UI, some vanilla logic in the middle tier, and data access. That is all. It is THE most important thing to know what you don't need. And this isn't bitter-old-man stuff. Rather, it's bright-young-man-with-better-things-to-do stuff, is what it is. Use frameworks and patterns to remove the makework out of developing software, not to put it in. Data access and logging modules are things you should never, ever, have to write. Another very real way of looking at it is saying that you should reduce the amount of code you write to the bare minimum. That reduces the potential error footprint. Don't go around solving problems that don't exist. Rather, concentrate on the ones that do. :thumbsup: [Edit] Thanks for the 5 votes guys. But, Ahmed, dude? Get out more... :cool: I hasten to add that I have personal experience of making a project much more tiresome than it should have been because I went in guns hot with factory patterns and generics and doodads of every description. Never again. So, I guess, do as I say, not as I do... I have also spent the last two months rewriting a monstrous desktop app which does some very simple things in extremely complex ways, because three separate contractors came in with their own twatfaced opinions about what constituted a proper DAO layer. Ludicrous.
Smokie, this is not 'Nam. This is bowling. There are rules. http://melpadden.wordpress.com LinkedIn
Mel Padden wrote:
I have also spent the last two months rewriting a monstrous desktop app which does some very simple things in extremely complex ways, because three separate contractors came in with their own twatfaced opinions about what constituted a proper DAO layer. Ludicrous.
I spend days making a bit of code depend more upon abstractions because it just could not do what we wanted it to do, while it should've been able to do that. I had proposed the abstractions earlier on in the design process, but 'they were not necessary and only complicated things'... Then, about two months later, we DID need the abstractions. We were feverishly Inheriting code we didn't need just so we didn't have to copy/paste a couple of 100's of lines that we wanted to re-use, but couldn't due to some missing abstractions. I was still able to add the extra layer of abstractions, but it cost me a couple of days that could have been saved had we done it right from the start. The design is nice and clean now and there is no duplicate code (just a couple of Interfaces extra). Your story is also very true and nicely said. I just wanted to illustrate an opposite case where things were not 'complex' enough (in my experience design is usually perceived as 'added complexity') :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
Don't do it - you're just adding a layer for the sake of it - unless you can prove it adds something to the project or is absolutely required then remind said pup that simply adding complexity because it is clever does not make it better.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
What Mark said. This notion of "if we don't add this feature it won't be enterprisy enough is bad. Don't solve problems which don't actually exist. Upon the first need for the new layer, implement the solution at that time. You'll be surprised how often the layer you thought was necessary turns out not to be. It is good, though, to consider those alternatives. That way, you can design your solution in such a way that minimizes the difficulty of extending it in a way you anticipate needing in the future without spending time to actually implement that extension.
-
In that case I would create a view model for the business entity that needed the drop down or use ViewData. I am against creating view models for all of the business entities just so we can say we have a view model layer.
"The ViewDataDictionary approach has the benefit of being fairly fast and easy to implement. Some developers don’t like using string-based dictionaries, though, since typos can lead to errors that will not be caught at compile-time. The untyped ViewDataDictionary also requires using the as operator or casting when using a strongly typed language like C# in a View template. An alternative approach that we could use is one often referred to as the ViewModel pattern. When using this pattern, we create strongly typed classes that are optimized for our specific View scenarios and that expose properties for the dynamic values/content needed by our View templates. Our Controller classes can then populate and pass these View-optimized classes to our View template to use. This enables type safety, compile-time checking, and editor IntelliSense within View templates." ViewModels don't have to be inherited from the entities though, although it' still better than using only entities imho.
