5 ms·

The risk of the new one or the risk of keeping the old 100K lines? Half serious question since I would estimate the risk of the latter to be much larger.

by croon 7y ago

gmueckl 7y ago
To me it sounds like he was introducing a hard dependency on AspectJ, which is as much a risk as any other dependency. I am guessing here, bit it is a scenario where a hissy fit from management has at least some justification.
- scarface74 7y ago
  How is a dependency on AspectJ any more of a liability than the dozens of other external dependencies in your typical application?
  - gmueckl 7y ago
    It is just as much of a liability, a priori neither more nor less. It needs to be evaluated like any other potential new dependency. Plus, AspectJ is something that you have to be careful with. It injects code at the start or end of methods that can do arbitraty things and the method source code doesn't indicate that this is happening. So it has a great potential for code obfuscation.
    - scarface74 7y ago
      Sort of unrelated rant. Maybe it’s because I’m not as well versed in Java idioms as I am with C# idioms, but using code that implements AOP using AspectJ seems much more obtuse than what I’ve done in C# just looking at the examples. In C#, with the various frameworks - including on the API level with ASP.Net - you can use attributes to decorate the classes/methods with your aspects and it’s pretty easy to see what it’s doing. You get the runtime binding basically by just using dependency injection as you always do.
      - logicalmind 7y ago
        C# dev here as well, but from a Java background. When I first moved to C# from Java one of the best AOP usages was transaction management. Database transaction management. You could write all of the code, whether it was dependent upon the db or not, and then decorate the methods with a transaction attribute. This decoration contained all the logic to get a db connection, begin a transaction, become part of an existing one, or create a new isolated one. Any unhandled exception caused the final unwinding to rollback any work that had been done in that transaction. So many try/catch/finally's avoided and so much boilerplate code. I have yet to find any equivalent to this .NET world. Especially of you're using EF. Either you use ADO and have your try/catch/finally with manual transaction management, or you have the EF context which is just one big blob you hope succeeds at the end.
        scarface74 7y ago
        TransactionScope has been around forever in the .Net Franework version of EF. It just came back to EF Core in 2.1 https://www.google.com/amp/s/codewala.net/2018/05/06/transactionscope-a-simple-way-to-handle-transactions-in-net/amp/ https://www.google.com/amp/s/codewala.net/2018/05/06/transac...
        logicalmind 7y ago
        Yes, this is exactly the type of boilerplate I am talking about. All those usings and try/catch blocks which add needless code. It is possible to compose all of this into an aspect which then decorates your methods. Maybe I'm not being clear, so here is what I mean. Say you have a method that does some work, but calls some other thing to do some auditing. The auditing is nice, but it failing shouldn't halt the world. [Transaction] DoYourBusinessWork() { ...; AlsoAudit(); } [Transaction(RequiresNew, NoRollbackFor(AuditException)] AlsoAudit() { ... } The TransactionScope is handled in the aspect. Commit/Rollback is all handled there is well. There are not usings or exception handlings within your methods unless you want to handle those specifically.
        7y ago

The risk of the new one or the risk of keeping the old 100K lines? Half serious question since I would estimate the risk of the latter to be much larger.

by croon 7y ago

The risk of the new one or the risk of keeping the old 100K lines? Half serious question since I would estimate the risk of the latter to be much larger.

gmueckl 7y ago

To me it sounds like he was introducing a hard dependency on AspectJ, which is as much a risk as any other dependency. I am guessing here, bit it is a scenario where a hissy fit from management has at least some justification.

scarface74 7y ago
How is a dependency on AspectJ any more of a liability than the dozens of other external dependencies in your typical application?
- gmueckl 7y ago
  It is just as much of a liability, a priori neither more nor less. It needs to be evaluated like any other potential new dependency. Plus, AspectJ is something that you have to be careful with. It injects code at the start or end of methods that can do arbitraty things and the method source code doesn't indicate that this is happening. So it has a great potential for code obfuscation.
  - scarface74 7y ago
    Sort of unrelated rant. Maybe it’s because I’m not as well versed in Java idioms as I am with C# idioms, but using code that implements AOP using AspectJ seems much more obtuse than what I’ve done in C# just looking at the examples. In C#, with the various frameworks - including on the API level with ASP.Net - you can use attributes to decorate the classes/methods with your aspects and it’s pretty easy to see what it’s doing. You get the runtime binding basically by just using dependency injection as you always do.
    - logicalmind 7y ago
      C# dev here as well, but from a Java background. When I first moved to C# from Java one of the best AOP usages was transaction management. Database transaction management. You could write all of the code, whether it was dependent upon the db or not, and then decorate the methods with a transaction attribute. This decoration contained all the logic to get a db connection, begin a transaction, become part of an existing one, or create a new isolated one. Any unhandled exception caused the final unwinding to rollback any work that had been done in that transaction. So many try/catch/finally's avoided and so much boilerplate code. I have yet to find any equivalent to this .NET world. Especially of you're using EF. Either you use ADO and have your try/catch/finally with manual transaction management, or you have the EF context which is just one big blob you hope succeeds at the end.
      - scarface74 7y ago
        TransactionScope has been around forever in the .Net Franework version of EF. It just came back to EF Core in 2.1 https://www.google.com/amp/s/codewala.net/2018/05/06/transactionscope-a-simple-way-to-handle-transactions-in-net/amp/ https://www.google.com/amp/s/codewala.net/2018/05/06/transac...
        logicalmind 7y ago
        Yes, this is exactly the type of boilerplate I am talking about. All those usings and try/catch blocks which add needless code. It is possible to compose all of this into an aspect which then decorates your methods. Maybe I'm not being clear, so here is what I mean. Say you have a method that does some work, but calls some other thing to do some auditing. The auditing is nice, but it failing shouldn't halt the world. [Transaction] DoYourBusinessWork() { ...; AlsoAudit(); } [Transaction(RequiresNew, NoRollbackFor(AuditException)] AlsoAudit() { ... } The TransactionScope is handled in the aspect. Commit/Rollback is all handled there is well. There are not usings or exception handlings within your methods unless you want to handle those specifically.
        7y ago