I'm using AutoMapper v9.0 in a ASP.net Core web api and after an extended time of adding, modifying and removing mappings in my profile classes I am starting to loose track of which mappings are actually used. In some cases the mapped classes still exist so the solution compiles without errors, but for one reason or another there might not be any need to map between these anymore. Is there a way to easily identify any orphan mappings so that I can remove them?
Related
I know this is somewhat subjective, but Symfony being as it is there must be a feature specifically designed for this purpose.
Here are the main factors of what I need to do:
The system will be deployed separately for multiple customers (probably just a handful. scale isn't a big concern).
Each deployment has a small amount of highly bespoke functionality specific to the customer. This could be anything.
I want to maintain a single, common codebase (including composer.json). The only file I really want outside of our repo is parameters.yml.
My current thinking involves a custom bundle for every customer - hooking into them using custom Symfony events, fired from the common parts of the system. But ...
Symfony bundles aren't designed to be dynamically registered. They're baked into our core system so I can't switch them on and off for individual customers without forking/splitting the codebase. This means not only a bloated Kernel, but also events would be received by all bundles in all deployments.
I can get around that last point by namespacing the events with a configuration parameter. Even if I can live with redundant bundles in the Kernel, this whole approach seems too hard to be correct.
What is the proper way to support a "pluggable" architecture than I can hook into from the core system without splitting my codebase?
I use multiple app-directories. Then you can turn on/off bundles for each client since each client has it's own AppKernel.php and then you can create a separate /web/app.php for each client and point it to the currect app-directory.
You can then use mod-rewrite in Apache to point each client's subdomain or something to the right app.php file
I have the main website that uses a database to store and access user accounts. I'm using EF to manage the schema. I also defined site-specific POCOs and have migrated them to the database.
Now, what if I want a separate website, for example, a resource server (Web API) that would expose (with authorization) the same data set up on the main website?
Do I create the same POCOs and derived DbContext on the resource server again? That seems like duplicating work, though.
What if I wanted to create new POCOs on the resource server and reflect them onto that same database? Wouldn't that conflict with the current migration (which is saved on the database), then subsequently mess up the EF setup on the main website?
I've seen the suggestion of putting the POCOs and DbContexts in a library and have multiple projects reference that same library. This seems viable, however I'd have to hard-code the connection string, which seems dirty to me.
I'm starting to think that EF is probably not recommended for this kind of setup. It seems like a database-first approach plays better here - though I would have to manually reedit the data contexts (most likely, LINQ-SQL) for every database schema change.
Are there any lesser-known capabilities, facts, practices, etc., for/about EF that would help in this situation?
Generally, you can avoid duplication by having one API serving both sites and have resources version for each if needed. On the other hand, if you choose reuse and add approach, creating additional EF code-first entities should not interfere with other site data layer if modeled and mapped carefully. DbContext connection string does not have to be hard-coded.
I have just started working on entity framework in an ASP.net application and I was wondering if someone could point in the right direction with respect to best practices. I have some questions in particular which I have listed below.
First of all I am using entity framework 4.0. I already have my database created and so I created a class library and generated the entity model from the database. I had been using Guids generated by the database so I had to modify the ssl to include the attribute StoreGeneratedPattern="Identity". Is there a way to do this automatically or do I have to manually edit the ssl everytime I update the database and the model? (For those of you know are facing a problem with guids or want to know why I am doing this.. this is a clear article on the problem with auto generated GUIDs)
I was planning on using a single file in the class library to hold all the database queries. Is this good practice? How would I ensure different programmers dont rewrite the same queries over and over?
I was planning on using a unique context per method. Is this the right way to go? I read through Rick Strahl's post on context lifetime management. But I am still not sure if a unique context per method is the right way to go.
Can I have my database queries as static methods since they do not make use of any instance variables?
If I use a unique context per method as mentioned in 3 and I wish to modify an entity object returned by one context what would be the best practice? Do I use the attach functionality to attach the object to a new context and save the changes ? I havent tried this but I have read a couple of articles and it seems a bit straightforward but wanted to know if there are any alternatives to this.
If you any suggestions on how you use Entity Framework in an ASP.net application I definitely could use help. This is my first ASP.net/Entity framework application so any tips will help
This was issue in initial version of VS 2010. In some cases this should already work correctly once you have VS 2010 SP1 installed. If it doesn't install this KB.
You can easily get huge class with a lot of static methods. Try to use some separation by the entity type you are querying. You will never fully ensure that another programmer will not create the same query again. This is about correct query naming following same naming policy, documentation and communication among programmers.
Unique context "per method" is usually not needed. In most cases you should be happy with unique context per logical (business) transaction - in case of web application logical operation is in most cases single request processing = one context per request.
If you pass context instance to your queries the answer is yes. Once you don't create them as static and they will take context instance from their class instance you will be very close to repository pattern.
This is exactly problem with context per method and it is hard to solve because to make this work you must first detach entity from the first context and attach it to the second context. If your entity has also related entities loaded all these relations will be nulled during detaching (unless you use deep clone instead of detaching = creating second instance of the entity).
I'm working on an ASP.Net website along with a supporting Class Library for my Business Logic, Data Access code, etc.
I'm EXTREMELY new and unfamiliar with the Unity Framework and Dependency Injection as a whole. However, I've managed to get it working by following the source code for the ASP.NET 3.5 Portal Starter Kit on codeplex. But herein lies the problem:
The Class Library is setup with Unity and several of my classes have [Dependency] attributes on their properties (I'm exclusively using property setter injections for this). However, the Global.asax is telling Unity how to handle the injections....in the Class Library.
Is this best practice or should the Class Library be handle it's own injections so that I can re-use the library with other websites, webapps or applications? If that is indeed the case, where would the injection code go in this instance?
I'm not sure how clear the question is. Please let me know if I need to explain more.
Though not familiar with Unity (StructureMap user) The final mappings should live in the consuming application. You can have the dll you are using define those mappings, but you also want to be able to override them when needed. Like say you need an instance of IFoo, and you have one mapped in your Class Library, but you've added a new one to use that just lives in the website. Having the mappings defined in the site allows you to keep things loosely coupled, or else why are you using a DI container?
Personally I try and code things to facilitate an IOC container but never will try and force an IOC container into a project.
My solution breakdown goes roughly:
(Each one of these are projects).
Project.Domain
Project.Persistence.Implementation
Project.Services.Implementation
Project.DIInjectionRegistration
Project.ASPNetMVCFrontEnd (I use MVC, but it doesn't matter).
I try to maintain strict boundaries about projects references. The actual frontend project cannot contain any *.Implementation projects directly. (The *.implementation projects contain the actual implementations of the interfaces in domain in this case). So the ASPNetMVCFrontEnd has references to the Domain and the DIInjectionWhatever and to my DI container.
In the Project.DIInjectionWhatever I tie all the pieces together. So this project has all the references to the implementations and to the DI framework. It contains the code that does the registering of components. Autofac lets me breakdown component registration easily, so that's why I took this approach.
In the example here I don't have any references to the container in my implementation projects. There's nothing wrong with it, and if your implementation requires it, then go ahead.
With NInject (preferably 2.0), what options do we have wrt wiring up our object dependencies in a web application?
Can they be defined in an XML configuration file?
Or does it have to be done via code?
There is an extension for xml based configuration: https://github.com/ninject/ninject.extensions.xml
You can do a lot more powerful binding in code though.
Ninject doesn't have XML configuration, sorry but I can't provide a direct link (cos their site has flash elements), but here is a quotation from ninject.org:
Free yourself from XML
Most other .NET dependency injection
frameworks are designed around the use
of XML to declare type bindings.
Rather than forcing you to write
cumbersome and error-prone text,
Ninject arms you with a fluent
interface, which lets you connect the
pieces of your application using
full-fledged code. This means you can
take advantage of the features of the
IDE and compiler, like code completion
and type-safety.
The problem I see with defining bindings in the code only is that you have to add reference to the dll.
You cannot change the binding without adding reference to new dll (removing reference to old one), change code and recompile.
If we had xml config I wouldn't need reference at all, and wouldn't have to recompile.
Right now I have MVC app that is using DI to pass repositories to Controllers. Nothing else then Ninject code for adding bindings uses the concrete implementations of repositories. And still I need to add reference to dll containing the implementations. For only one line of code!
Or maybe there is a possibility to achieve this using Ninject?
What are you looking to achieve? What sort of stuff are you looking to configure? Dynamically selecting a Strategy ? Passing in Port numbers? You could offer a lot more information as to what you're thinking in order to get a better answer [that you can acccept :P].
You need to split the concerns of:
known object wiring (DI)
configuration - generally you'll want to split those into small focused subsets e.g. Strongly Typed config elements vs having a global pool of settings in a big pile mishmashed together a la appSettings
plugins / unknown object wiring (MEF?)
In the first pool, doing it in Code is just the right way and I cant think of any advantage XML would give, esp. in the context of strong names etc.