I'm learning Scala/Play2.1.3 from a C#/.Net/ASP.NET MVC background.
I wonder why there is no dependency injection support by default?
In Play samples, all data-access methods are static in the domain model classes. They use factories instead of injections. What if I want to mock some data-access methods for unit-testing?
There is no ready-to-use high-level ORM there. Actually they discourage me to use ORMs! Regarding SQL DBs I can't believe that I have to write joins again which I don't remember the last time I wrote a join clause. Isn't it a step backward?
I've learned to use SOLID principals which are not observed in Play framework (completely) IMO.
Am I wrong your I should consider using another framework?
You are right, the majority of samples does not use Dependency Injection. But since the 2.1 version, it is possible to inject the controllers, and their dependencies.
For the dependency injection, check the doc and also, how to unit test (last paragraph).
But since there are many static calls, you could end up with some static reference somewhere and you'll not be able to unit test your code.
But I think Play is a great framework, the team is modularizing more and more the framework, so that it will be better and better regarding SOLID principles.
Related
I was following this tutorial for EF Core with ASP.NET Core. The interesting thing is that this article states that 'the use of Repository and unit of work patterns is not always the best choice for applications that use EF', but in the tutorial of EF 5 the use of repository and unit of work patterns still is promoted even with a seperate tutorial part.
Reading old articles on stackoverflow it is reported that the reasons one would apply it is mainly for testing (dependency injection).
Reading further in the turial it is mentioned that 'The Entity Framework Core implements an in-memory database provider that can be used for testing'. I presume this is a new feature that was not there at the time of EF5. Does this mean that there is hardly any reason anymore to apply the use of repository and unit of work patterns in EF Core with ASP.NET Core?
There's many reasons and a long history for why there's so much confusion here. EF's DbContext used to not implement an interface, so it made mocking it difficult for testing purposes. However, that was corrected in EF 6, so since that time there's been absolutely no benefit, even for testing purposes, in using the repository/unit of work patterns.
EF Core is completely testable end-to-end and has an in-memory database provider as well now, which means you don't even need to mock it, though you very much can if you want.
Long and short, dump the repository and unit of work patterns. They've never been a good solution even when they had some use for testing, and since EF 6, they have been completely useless.
Now... let the flame war begin.
If given an option to use Sling Models or WCM use class which one should be preferred when and why?
Is either of them better performance wise?
Thanks in Advance
Sling models are saving you a lot of time for accessing simple objects as the current page/resource, injecting some properties or services, adapting from resource or sling http request to your model. Sure with the use the plain API your code will execute a little bit faster, because you initialize only the objects you really need, but you have to do all that things "manually". I think that this sightly introduction is giving a good overview of all possible implementation you can go with. You can also have a look at the sightly official documentation. Below you can find a quick overview of the what you can expect and hopefully make your decision easier (quoted from the offical sightly documentation).
Java Use Provider
Advantages
Use-objects provided through bundles:
faster to initialise and execute than Sling Models for similar code
easy to extend from other similar Use-objects
simple setup for unit testing
Use-objects backed by Resources:
faster to initialise and execute than Sling Models for similar code
easy to override from inheriting components through search path
overlay or by using the sling:resourceSuperType property, allowing
for greater flexibility
business logic for components sits next to the Sightly scripts where
the objects are used
Disadvantages
Use-objects provided through bundles:
lacks flexibility in terms of component overlaying
Use-objects backed by Resources:
cannot extend other Java objects
the Java project might need a different setup to allow running unit
tests, since the objects will be deployed like content
Sling Models Use Provider
Advantages
convenient injection annotations for data retrieval
easy to extend from other Sling Models
simple setup for unit testing
Disadvantages
lacks flexibility in terms of component overlaying, relying on
service.ranking configurations
If you ask me I would always take a framework as sling models or slice which makes the development easier and faster. At the end the performance impact by using a framework is not really a problem, would be not the only one third party framework in the project. But if your project is performance oriented probably you could make some tests with all possibilities you have and decide if such a framework suits your needs (or just mix both).
I've been reading about the benefits of implementing DI on iOS, but I have one doubt: where should I put the code that actually creates instances of objects? Is it factory pattern the recommended way to go about this? should all instances be created on the same factory? I've been checking out some frameworks like Typhoon but they all seem over-engineered to me for something as simple as dependency injection. I don't want to overwhelmed my app by using any of these frameworks, so I'm trying to keep it simple, at least for now.
My development team is evaluating the various frameworks available for .NET to simplify our programming, one of which is CSLA. I have to admit to being a bit confused as to whether or not CSLA would benefit from being used in conjunction with a dependency injection framework, such as Spring.net or Windsor. If we combined one of those two DI frameworks with, say, the Entity Framework to handle ORM duties, does that negate the need or benefit of using CSLA altogether?
I have various levels of understanding of all these frameworks, and I'm trying to get a big picture of what will best benefit our enterprise architecture and object design.
Thank you!
CSLA is a framework for creating business entities, so has separate concerns than an IoC container or ORM. In a enterprise application you should consider the benefits of all three.
In particular, you should consider CSLA if you want data binding built in to your models, dirty checking, N-level undo, validation and business rules, as well as the data portal implementation which allows easy configuration for n-tier deployments.
Short answer: Yes.
Long answer: It requires a bit of grunt work and some experimentation to setup, but it can be done without fundamentally breaking CSLA. I put together a working prototype using StructureMap and the repository pattern and used the BuildUp method of Setter Injection to inject within CSLA. I used a method similar to the one found here to ensure that my business objects are re-injected when the objects are serialized.
I also use the registry base class of StructureMap to separate my configuration into presentation, CSLA client, CSLA server, and CSLA global settings. This way I can use the linked file feature of Visual Studio to include the CSLA server and CSLA global configuration files within the server-side Data Portal and the configuration will always be the same in both places. This was to ensure I can still change the Data Portal configuration settings in CSLA from 2 tier to 3 tier without breaking anything.
Anyway, I am still weighing the potential benefits with the drawbacks to using DI, but so far I am leaning in the direction of using it because testing will be much easier although I am skeptical of trying to use any of the advanced features of DI such as interception. I recommend reading the book Dependency Injection in .NET by Mark Seemann to understand the right and wrong way to use DI because there is a lot of misinformation on the Internet.
Can't we use entity framework without unitof work pattern. What are the advantages and disadvantages
Entity framework has unit of work internally implemented you can't simply use it without that. If you load entities and modify them they are not persisted to database until you call SaveChanges.
If your question is more about "Should I use custom implementation of unit of work?" the answer depends on many factors. Generally you don't need it. Custom UoW is usually used with repositories. Repositories are in turn sometimes used to hide interaction with EF and make your upper layers persistance ignorant. Another reason for using repositories is better testability of your upper layers. But in my opinion neither of these two patterns is really needed with modern ORM tools.