Supposing a critical part of an application's business rules are dependent on a given behavior, but that coding this behavior explicitly will clutter your code, would you rely on encapsulating it in an aspect with PostSharp (or with any other aspect framework for that matter)? Is that a "safe" and "wise" option, or is it always better to explicitly code the behavior no matter how it will clutter the code? What about the maintainability of such a solution?
It is not recommend putting business rules or business logic in aspects. It defeats the purpose of AOP. Business rules/logic are not cross cutting concerns. If you consider part of your business logic as clutter then you should use common OOP practices to abstract it or extract it into it's own method(s).
You can, of course, move it into an aspect, but what would the goal be? To reduce clutter? That isn't acceptable to me. Use aspects to remove clutter not related to business logic so that your business logic is clear. If your business logic is cluttered then you need to refactor.
PostSharp vs other AOP frameworks: If you do end up putting "critical code" into an aspect, then PostSharp will be the best framework to get the best performance. Runtime frameworks like IoC contains that do dynamic interception will not perform as well as statically compiled code. Plus, PostSharp has so many optimizations that it performs based on the code you write that no other framework can match.
Related
I have recently learned of the Repository and Unit of Work Design Patterns and thought that I would implement them in a new EF4 MVC3 project, since abstraction is generally good.
As I add them to the project, I am wondering if the juice is worth the proverbial squeeze, given the following:
It is EXTREMELY unlikely that the underlying data access mechanism will change from EF4.
This level of abstraction will require more overhead/confusion to the project and to other developers on the team.
The only real benefit I see to using the Repository pattern is for unit testing the application. Abstracting away the data store doesn't seem useful since I know the datastore won't change, and further, that EF4 already provides a pretty good abstraction (I just call .AddObject() and it looks like I am modifying an in-memory collection and I just call .SaveChanges() which already provides the unit of work pattern).
Should I even bother implementing this abstraction? I feel like there must be some massive benefit that I am missing, but it just doesn't feel like I need to go down this route. I am willing to be convinced otherwise; can someone make a case? Thanks.
I recommend you reading this answer and all linked questions. The repository is very popular pattern and it really makes your application nice and clean. It make you feel that your architecture is correct but some assumptions about repository pattern with EF are not correct. In my opinion (described in those answers):
It will make some more complex EF related task much harder to achieve or your repository and UoW implementation will need to have public interface very similar to EF's
It will not make your code better unit testable because all interactions with repository must still be covered by integration tests. Not only my experience proved that mocking EF code by replacing linq-to-entities with linq-to-objects does not test your code.
yes yes yes : ) - first of all - the repository pattern helps to inject your dependencies for unit testing. Secondly, it gives a very clear view of exactly what data access methods are available to get something rather than people misc. coding against the EF layer directly. Download the POCO templates though for EF4 so your classes don't carry the EF properties around with them if you happen to use them as models and/or don't want any EF dependency libraries references in your mvc app assuming your repository work is in a separate project (which I recommend). If you are using all viewmodels then its not as much of a concern, but its nice working with a "Customer" object without extra methods on them. Its cleaner in my opinion.
I am looking at the Lhotka CSLA.NET object library (Lhotka.NET). It seems interesting, but one thing which does not make sense is that the business rules are written in C#. Should these not be coded outside of code (even though it would be a library which is not coupled to the main logic of an app the rules can still change and require recompiling).
Thanks
No, that would be the inner platform anti-pattern.
If you make a system that is advanced enough to handle any business rule that you might possibly need, it will be much more complicated than it has to be.
CSLA business rules are just delegates that return true if the rule passes and false if it does not.
Since the business rules are just code, you are free to do whatever you like. You can create a rules engine if you wish and process the rules outside the objects if you wish.
CSLA also supports attribute based DataAnnotations if you wish to use attribute based rules as well.
Starting in Csla 4, the static rule methods are no longer supported. Instead you create a class which is a subclass of BusinessRule in the Csla.Rules namespace. This allows for better reuse and easier unit testing.
My company needs to rewrite a large monolithic program, and I would want it written using a plugin type architecture. Currently the best solution appears to be MEF, but as it is a fairly 'new' thing I am warey of betting the future of my company (and my reputation) on it.
Does anyone have a feeling on how mature a solution MEF is ?
Thanks
Visual Studio's entire extension system is now built on MEF.
That is to say that Microsoft is Dog-fooding it (like they are doing with WPF).
Given that the framework developers themselves will be working with it, you can feel pretty confident that it is here to stay. However, as with any first release, you are almost guaranteed to have some growing pains when the next release comes around.
Personally, I would go for it. It is certainly better than the tightly-coupled-reflection-based alternative.
I don't think it is necessary to "bet on MEF". Your code should have very little dependencies on MEF.
You can use the technique of dependency injection to break up your monolithic application into components which have only a single responsibility, and which limit their knowledge of other components to abstractions. See this blog post by Nicholas Blumhardt for a nice overview of the type of relations that can exist between components.
Wiring the components together into an application can then be done with any dependency injection framework, or even manually. The component logic shouldn't need to be aware of the container - there might not even be a container.
In the case of MEF, you do need to add import/export attributes to your classes. However, you can still ignore those attributes and reuse those components without MEF, e.g. by using another DI framework like AutoFac.
It's a relatively new technology, so I'm not sure if it's exactly mature. I'm sure it will change quite a bit over the next several years, perhaps merging with other frameworks to better support IoC. That said, MS has a pretty good history of preserving backwards compatibility, so now that MEF is actually part of the Framework, I would consider the public interfaces stable.
That said, MEF might not actually be the right solution for your project. It depends on your extensibility needs and how large is 'large'. If you want to support true extensibility, including the possibility for third-party plugins, it has an enormous impact on your design responsibilities. It's much harder to make changes to the infrastructure as you now need to maintain very stable public interfaces. If you're really only after the IoC features, you're probably better off with a true IoC framework, which more clearly limits your design responsibility to support of your internal dependencies. If you're betting the future of the company, this is the bigger question, in my mind.
Looking at Microsoft's Managed Extensibility Framework (MEF) and various IoC containers (such as Unity), I am failing to see when to use one type of solution over the other. More specifically, it seems like MEF handles most IoC type patterns and that an IoC container like Unity would not be as necessary.
Ideally, I would like to see a good use case where an IoC container would be used instead of, or in addition to, MEF.
When boiled down, the main difference is that IoC containers are generally most useful with static dependencies (known at compile-time), and MEF is generally most useful with dynamic dependencies (known only at run-time).
As such, they are both composition engines, but the emphasis is very different for each pattern. Design decisions thus vary wildly, as MEF is optimized around discovery of unknown parts, rather than registrations of known parts.
Think about it this way: if you are developing your entire application, an IoC container is probably best. If you are writing for extensibility, such that 3rd-party developers will be extending your system, MEF is probably best.
Also, the article in #Pavel Nikolov's answer provides some great direction (it is written by Glenn Block, MEF's program manager).
I've been using MEF for a while and the key factor for when we use it instead of IOC products is that we regularly have 3-5 implementations of a given interface sitting in our plugins directory at a given time. Which one of those implementations should be used is actually something that can only be decided at runtime.
MEF is good at letting you do just that. Typically, IOC is geared toward making sure you could swap out, for a cononical example, an IUserRepository based on ORM Product 1 for ORM Product 2 at some point in the future. However, most IOC solutions assume that there will only be one IUserRepository in effect at a given time.
If, however, you need to choose one based on the input data for a given page request, IOC containers are typically at a loss.
As an example, we do our permission checking and our validation via MEF plugins for a big web app I've been working on for a while. Using MEF, we can look at when the record's CreatedOn date and go digging for the validation plugin that was actually in effect when the record was created and run the record BOTH through that plugin AND the validator that's currently in effect and compare the record's validity over time.
This kind of power also lets us define fallthrough overrides for plugins. The apps I'm working on are actually the same codebase deployed for 30+ implementations. So, we've typically go looking for plugins by asking for:
An interface implementation that is specific to the current site and the specific record type in question.
An interface implementation that is specific to the current site, but works with any kind of record.
An interface that works for any site and any record.
That lets us bundle a set of default plugins that will kick in, but only if that specific implementation doesn't override it with customer specific rules.
IOC is a great technology, but really seems to be more about making it easy to code to interfaces instead of concrete implementations. However, swapping those implementations out is more of a project shift kind of event in IOC. In MEF, you take the flexibility of interfaces and concrete implementations and make it a runtime decision between many available options.
I am apologizing for being off-topic. I simply wanted to say that there are 2 flaws that render MEF an unnecessary complication:
it is attribute based which doesn't do any good to helping you figuring out why things work as they do. There's no way to get to the details burred in the internals of the framework to see what exactly is going on there. There is no way to get a tracing log or hook up to the resolving mechanisms and handle unresolved situations manually
it doesn't have any troubleshooting mechanism to figure out the reasons for why some parts get rejected. Despite pointing at a failing part it doesn't tell you why that part has failed.
So I am very disappointed with it. I spent too much time fighting windmills trying to bootstrap a few classes instead of working on the real problems. I convinced there is nothing better than the old-school dependency injection technique when you have full control over what is created, when, and can trace anything in the VS debugger. I wish somebody who advocates MEF presented a bunch of good reasons as to why would I choose it over plain DI.
I agree that MEF can be a fully capable IoC framework. In fact I'm writing an application right now based on using MEF for both extensibility and IoC. I took the generic parts of it and made it into a "framework" and open sourced it as its own framework called SoapBox Core in case people want to see how it works.
In particular, take a look at how the Host works if you want to see MEF in action.
I'd like a dead simple explanation of policy injection for less-informed co-workers. Where is a good resource for this? I learned about policy injection from the entlib help files, which I'm sure aren't the best option.
The MSDN documentation for Policy Injection has a pretty clear explanation:
Applications include a mix of business
logic and crosscutting concerns, and
the two are typically
intermingled—which can make the code
harder to read and maintain. Each task
or feature of an application is
referred to as a "concern." Concerns
that implement the features of an
object within the application, such as
the business logic, are core concerns.
Crosscutting concerns are the
necessary tasks, features, or
processes that are common across
different objects—for example,
logging, authorization, validation,
and instrumentation. The purpose of
the Policy Injection Application Block
is to separate the core concerns and
crosscutting concerns.
Simply put, the PI block lets developers define a set of policies that specify the behavior of objects in the system. So your core business logic, such as the code that calculates profit per unit in a fiscal year (one concern), is separated from the logging of that execution of logic (another, but more often used, concern).
The same documentation says that the PI block is not AOP because:
It uses interception to enable only pre-processing handlers and post-processing handlers.
It does not insert code into methods.
It does not provide interception for class constructors.
So trying to look at PI from an AOP perspective can muddy the waters a bit.
What the EntLib calls Policy Injection, is really Aspect Oriented Programming. I wrote a post introducing the concepts of AOP on my blog a while back, maybe it'll be helpful.