How far is to far for separation of concerns?
-
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.
-
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.
What is the other developers reasoning for inheritting from the business entities? I would think there is some reason that they have proposed this. If they have a 'good' reason why not? It shouldn't really make the existing layers more complicated (assumming it was made correctly). Isn't that an advandage of N-Tier? (maybe not a direct advantage, but if the system was designed for multi -tier it should be easy to 'inject' another layer) With that said, if it is not easily done then the system already has problems and should be refactored to handle when new layers need be added. Also, if the developers reasoning is not sound (e.g. "I read a white paper that recomends this" or "Seems like a good idea" etc... no backing), then it seems silly. I highly doubt that as "most" developers do not add logic just for adding logic. (note: I used quotes on "most" as there are some individuals out there you need to watch out for. They impliment just to impliment. They work for more work. These individuals are in the wrong field, but not much you can do about it other than explain why the proposal has no justification)
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
What is the other developers reasoning for inheritting from the business entities? I would think there is some reason that they have proposed this. If they have a 'good' reason why not? It shouldn't really make the existing layers more complicated (assumming it was made correctly). Isn't that an advandage of N-Tier? (maybe not a direct advantage, but if the system was designed for multi -tier it should be easy to 'inject' another layer) With that said, if it is not easily done then the system already has problems and should be refactored to handle when new layers need be added. Also, if the developers reasoning is not sound (e.g. "I read a white paper that recomends this" or "Seems like a good idea" etc... no backing), then it seems silly. I highly doubt that as "most" developers do not add logic just for adding logic. (note: I used quotes on "most" as there are some individuals out there you need to watch out for. They impliment just to impliment. They work for more work. These individuals are in the wrong field, but not much you can do about it other than explain why the proposal has no justification)
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
He says it is easy to code generate and we may use it in the future so why not just do it. To me it add more complexity to the project when 99 percent of the time we won't need the view models. I would rather just create the view models when we need them. The reason he would like to inherit from the business entities is so we don't need to map a view model to a business entity. We could just pass the view model to the business logic directly.
-
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.
GateKeeper22 wrote:
99.9% of the time the view model will just be an empty class that inherits from the business entities.
Presumably there is real business functionality represented by that 00.1% rather than pie in sky whimsy by developer(s) about some nebulous thing occuring in the future. If no then absolutely not. If yes then what happens to the funtionality represented by that 00.1% if you don't implement another layer? It is impossible to do or just a bit awkward? If impossible then do it. If just awkward then stick to awkward because nothing is perfect and that is what comments are for.
-
GateKeeper22 wrote:
99.9% of the time the view model will just be an empty class that inherits from the business entities.
Presumably there is real business functionality represented by that 00.1% rather than pie in sky whimsy by developer(s) about some nebulous thing occuring in the future. If no then absolutely not. If yes then what happens to the funtionality represented by that 00.1% if you don't implement another layer? It is impossible to do or just a bit awkward? If impossible then do it. If just awkward then stick to awkward because nothing is perfect and that is what comments are for.
On the .1% of the time I add a view model to handle the difference and have a mapper function to copy the data from the business entity to the view model. It has only happened once so I only have one view model. I do it when it is need and the other developer wants to make it a standard an do it all the time even if it isn't needed.
-
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.
-
GateKeeper22 wrote:
I am against using adding another layer to the app and I want to find out what some other peoples opinions are.
What value does it add, and what will it cost? Good idea = (AddedValue > Cost)
Bastard Programmer from Hell :suss:
I can't see that it will add any value. It is pretty easy to implement if I do it by inheriting from the business entity. If I do it the way I have been by mapping the view model to the entity it would take more time but not to much. To me it isn't worth the extra work because we aren't really getting anything out of it expect another layer.
-
I can't see that it will add any value. It is pretty easy to implement if I do it by inheriting from the business entity. If I do it the way I have been by mapping the view model to the entity it would take more time but not to much. To me it isn't worth the extra work because we aren't really getting anything out of it expect another layer.
GateKeeper22 wrote:
To me it isn't worth the extra work because we aren't really getting anything out of it expect another layer.
Sounds like a good idea to delay it until you do need it. How much hours (and thus, money) would your co-worker spend on implementing it, and what benefit does he see in having that layer that's worth that cost?
Bastard Programmer from Hell :suss:
-
GateKeeper22 wrote:
To me it isn't worth the extra work because we aren't really getting anything out of it expect another layer.
Sounds like a good idea to delay it until you do need it. How much hours (and thus, money) would your co-worker spend on implementing it, and what benefit does he see in having that layer that's worth that cost?
Bastard Programmer from Hell :suss:
He would just add it to code generation so it wouldn't cost anytime. I haven't really gotten a good answer on what benefits it would give us. He just says it would be easy to generate and not take much time to implement so why not do it. To me that isn't a very good answer. I need to see the value that the layer will give us before I implement it. I would rather implement it on a case by case bases.
-
He would just add it to code generation so it wouldn't cost anytime. I haven't really gotten a good answer on what benefits it would give us. He just says it would be easy to generate and not take much time to implement so why not do it. To me that isn't a very good answer. I need to see the value that the layer will give us before I implement it. I would rather implement it on a case by case bases.
GateKeeper22 wrote:
He would just add it to code generation so it wouldn't cost anytime.
"Does not cost any time"? So you are sure that it doesn't need maintenance and will not cause bugs?
GateKeeper22 wrote:
I haven't really gotten a good answer on what benefits it would give us.
That makes it simple; we can generate a 2Gb data-file with random contents. That doesn't have much benefit either.
GateKeeper22 wrote:
He just says it would be easy to generate and not take much time to implement so why not do it.
..because it doesn't add any value to the project, only extra code. That code has to be tested, and not having that extra load of code means that there cannot be any bugs in there :)
Bastard Programmer from Hell :suss:
-
GateKeeper22 wrote:
He would just add it to code generation so it wouldn't cost anytime.
"Does not cost any time"? So you are sure that it doesn't need maintenance and will not cause bugs?
GateKeeper22 wrote:
I haven't really gotten a good answer on what benefits it would give us.
That makes it simple; we can generate a 2Gb data-file with random contents. That doesn't have much benefit either.
GateKeeper22 wrote:
He just says it would be easy to generate and not take much time to implement so why not do it.
..because it doesn't add any value to the project, only extra code. That code has to be tested, and not having that extra load of code means that there cannot be any bugs in there :)
Bastard Programmer from Hell :suss:
That is a good point about adding more bugs even if it is generated. Thank you for the info. I am adding all of your points to my argument. I am also glad to see that I am not the only one out there that would be against this.
-
On the .1% of the time I add a view model to handle the difference and have a mapper function to copy the data from the business entity to the view model. It has only happened once so I only have one view model. I do it when it is need and the other developer wants to make it a standard an do it all the time even if it isn't needed.
You don't re-arch a system based on extreme corner cases when work around exists. There are many real reasons why one doesn't do that for non-trivial applications which a multiple person system always is. Some of the ones that come to mind. 1. It adds complexity which increases maintenance cost. 2. There is no way to eliminate all corner cases. 3. A corner case can document itself but a re-arch requires much more explanation (and back to 1.) 4. The cost of a re-arch is much higher than implementing the corner case.
-
He would just add it to code generation so it wouldn't cost anytime. I haven't really gotten a good answer on what benefits it would give us. He just says it would be easy to generate and not take much time to implement so why not do it. To me that isn't a very good answer. I need to see the value that the layer will give us before I implement it. I would rather implement it on a case by case bases.
GateKeeper22 wrote:
He would just add it to code generation so it wouldn't cost anytime.
That means something needs to change. And you suggested that you are adding a layer and I use a lot of code generation and I can't think of a single example where adding a layer is a trivial fix.
GateKeeper22 wrote:
He just says it would be easy to generate and not take much time to implement so why not do it.
Nonsense. Almost everything in programming is easy. It is the sum of the parts that means that software costs money. Every addition costs money. Nothing that you have described suggests that this will have any net benefit. It certainly doesn't meet a business need. And it doesn't seem to meet any implementation need. So the other developer is attempting to rationalize some idealized view of how the world should be and ignoring the realities of large scale development.
-
GateKeeper22 wrote:
He would just add it to code generation so it wouldn't cost anytime.
That means something needs to change. And you suggested that you are adding a layer and I use a lot of code generation and I can't think of a single example where adding a layer is a trivial fix.
GateKeeper22 wrote:
He just says it would be easy to generate and not take much time to implement so why not do it.
Nonsense. Almost everything in programming is easy. It is the sum of the parts that means that software costs money. Every addition costs money. Nothing that you have described suggests that this will have any net benefit. It certainly doesn't meet a business need. And it doesn't seem to meet any implementation need. So the other developer is attempting to rationalize some idealized view of how the world should be and ignoring the realities of large scale development.
That is what I am thinking. We just took a class that had view models in it so now he wants to implement them. I have pretty much shot him down on it and I think the rest of the team is behind me on it. But only time will tell. Posting on this form helped me to realize that I am correct it is just adding another layer when one isn't needed. At least for the project we are currently working on it isn't. In future projects there may be a benefit to using them.
-
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.
If the reason is to remove presentation logic from the presentation layer ie sorting, FullName things like that. It sounds like a good idea. If the reason is because you are using an ORM and this means you can blow away the entities and recreate without losing that 0.1% of logic, it also sounds like a good idea. Doing it for the sake of it doesn't sound like a good idea.
"You get that on the big jobs."
-
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.
sexy girlï¼video for adult ï¼ more than 30 videos.http://sharecash.org/download.php?file=2531204
-
He says it is easy to code generate and we may use it in the future so why not just do it. To me it add more complexity to the project when 99 percent of the time we won't need the view models. I would rather just create the view models when we need them. The reason he would like to inherit from the business entities is so we don't need to map a view model to a business entity. We could just pass the view model to the business logic directly.
GateKeeper22 wrote:
He says it is easy to code generate and we may use it in the future so why not just do it.
The notion that just because some code gets generated automatically it therefore has zero cost (or even low cost) is a fallacy. "We may use it in the future" is not a very strong justification for anything. Lots of things may happen.