tag:blogger.com,1999:blog-6959582839690958035.post4538734471812209058..comments2023-09-15T11:15:54.222-04:00Comments on public void Life(): ORMs for all?testhttp://www.blogger.com/profile/09609860522747123959noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-6959582839690958035.post-66306834768599410982010-09-01T14:59:12.292-04:002010-09-01T14:59:12.292-04:00With regards to transactions, given the diverse nu...With regards to transactions, given the diverse number of data sources (not all of which are even databases) here, I really couldn't come up with any kind of universal transaction to create a proper unit of work. There's little choice but to create the framework for building atomic actions and have the developer handle transactions and such within those actions.<br /><br />I kind of view the whole thing as a great big MVC, with the resulting responses being the "views" and the handlers being the controllers and actions. The models need a little work, though, to have a less procedural approach. Currently the models used are the models returned, and I think I want to change that and split out the DTOs (returned objects) from the "Models" and have the proper models use the repositories as internal services.<br /><br />I have some tinkering to do :)testhttps://www.blogger.com/profile/09609860522747123959noreply@blogger.comtag:blogger.com,1999:blog-6959582839690958035.post-56058736330457983302010-09-01T14:47:53.737-04:002010-09-01T14:47:53.737-04:00This reminds me of one of Brion's posts about ...This reminds me of one of Brion's posts about why agile can't work in an enterprise. Things generally move too slowly.<br /><br />Problems with practices and technology usage can also be a team issue depending on the kinds of developers.<br /><br />In terms of your environment you certainly don't want the lazy loading and such to go over 2 boundaries. That would be only asking for trouble. I would think that each request should be responded to with all the data it needs to perform what it was triggered for. <br /><br />Yeah the UI should hopefully just receive dummy objects and hit a service or two to accomplish what it wants. A pattern of having the service return DTOs and a UI just generating action requests based on the user's interactions comes to mind. I can't think of the name but basically the UI would just create this requests in response to what the user wanted to do and when it hit a good place to do it, the UI would send a series of the requests back to the server.<br /><br />This plays well with what Agatha is doing and a series of action requests could be preformed in a single transaction and share no data very easily and safely given Agatha's request processors and NHibernate's 1st level cache.<br /><br />That is probably still not very helpful to you though.Copenhashttps://www.blogger.com/profile/14860283098628466896noreply@blogger.comtag:blogger.com,1999:blog-6959582839690958035.post-1909481960805477882010-09-01T13:04:28.654-04:002010-09-01T13:04:28.654-04:00Ya, the evolution of software design left this pla...Ya, the evolution of software design left this place in the dust long ago. I've tried more modern stuff, but skipping too many steps doesn't work well here. It's looking like we're going to have to re-discover everything the industry has already discovered, just hopefully at a more accelerated pace :)testhttps://www.blogger.com/profile/09609860522747123959noreply@blogger.comtag:blogger.com,1999:blog-6959582839690958035.post-75745018275241355082010-09-01T12:12:05.258-04:002010-09-01T12:12:05.258-04:00Yeah I haven't really been in an environment l...Yeah I haven't really been in an environment like that. This is why I like these discussion posts.<br /><br />What you have sounds like some kind of early take on SOA. I have heard that a lot of old systems were done this way and were generally not very clean.<br /><br />I'll have to think about your scenario some, but hopefully others will post some comments.Copenhashttps://www.blogger.com/profile/14860283098628466896noreply@blogger.comtag:blogger.com,1999:blog-6959582839690958035.post-14665221245542698262010-09-01T11:32:32.794-04:002010-09-01T11:32:32.794-04:00Where I'm currently at with ORMs is that the s...Where I'm currently at with ORMs is that the software ecosystem of my current job is _very_ procedural. I can't really blame them, it's a very procedural business and that layout of the code is just easier to grok and to support overall in this case. Not to mention that there is no "core domain" here, just separate applications doing separate things as part of a larger scope of "procedures." (I.E. App1 picks up some files and does something and writes to a DB, App2 later reads from the DB and does something and writes to another DB, App3 later does something else based on that data, etc.)<br /><br />In putting together code designs to fit this model, I've ended up with a very procedural anemic domain model (not unlike the one that was being built at our previous job, but a bit more procedural here). What this means is that the power of an ORM becomes less and less evident in this design. Thus, I've yet to really hit on one that gives proven results in this environment.<br /><br />Take lazy loading as an example. If the data access method is for an app to hit a service, which in turn asks a DAL repository for some data, does something with that data, and returns it to the app... where would lazy loading come in? The service's methods shouldn't be ORM-aware, should they? And any hope of lazy loading is gone once the data is sent back over that service boundary.<br /><br />Granted, the client's consumption of the service is itself an object model, so the client can lazy-load by having its objects make calls to the service. But if the effort here is to make the client apps as "dumb" as possible and have all the logic behind the service boundary, then that's complicating what should ideally be a very small and simple client application.<br /><br />And from the perspective of the service's methods and logic, there are _many_ repositories. Databases (of varying make and model), file system, 3rd party APIs, external services, etc. There's no "one database" that the overall domain uses. So, again, the benefits of an ORM don't really fit this scenario.<br /><br />If anybody has any thoughts on the subject, I'd love to hear it. I'm currently debating the idea of moving that service boundary up the stack and keeping the logic in the client apps, making their own individual models heavier. Not sure what ORMs would be able to do for me there either, though. And I fear that this would lead to increased diversification of logic and design and not really fix the mess we have now. And there's really something to be said for the testability/reproducibility/debugability of being able to encapsulate the logic into a request to be made to a single service, rather than having to reproduce steps in an unfamiliar application.testhttps://www.blogger.com/profile/09609860522747123959noreply@blogger.com