I searched for the same question over the net for a long time and couldn't find any detailed answer. like this answer :-Gets the ObjectContext for this LinqToEntitiesDomainService(Of TContext).(from msdn).
So my question is
No 1:- exactly ObjectContext Property do in domainservice ?
NO 2:- Can i overloads the property ?
NO 3:- What will happen if i overloads the property ?
The question can be strange but i really want to what exactly happens when i write Me.object context in domain service?
ObjectContext represent your entity models entities and functions.
It provides some methods for running with entities as if they are objects.
You can't override this property. It is not virtual.
It has SaveChanges,'ExecuteFunction' like methods .
Beside this you may extendyour domain service's features by inheritance
public partial class DSrvMy : LinqToEntitiesDomainService<AHBSEntitiesMy>
You may code a class extends from LinqToEntitiesDomainService<AHBSEntitiesMy> it would be your OwnDomainService and then you can override Invoke , Query,Submit,.. like operations in it.
You were be code a layer in ria services.
Related
I am working on a ClojureScript wrapper for qx.mobile and would like to programmatically build a cljs type hierarchy mirroring the qx class hierarchy.
Is there a way to get all the subclasses of a qooxdoo class?
How about a programmatic way to query the superclass of a class?
I am already putting qx.Class.getProperties to good use.
Thx, kt
The programmatic way of getting the superclass of a given class is documented at http://demo.qooxdoo.org/current/apiviewer/#qx.Class
<classname>.superclass
or getting the name of the superclass as a string
<classname>.superclass.classname
which means that e.g.
qx.ui.core.Widget.superclass.classname
will return the string "qx.ui.core.LayoutItem".
Regarding the programmatic way to retreive all subclasses of a class:
This is currently not possible without iterating the whole class hierarchy/tree and testing the objects against being subclasses of the given class.
We discussed at https://gitter.im/qooxdoo/qooxdoo that it maybe would be usefull to create an array for each class holding the subclasses. This could be added to the code of the private method __createClass in qx.Class.
We would like to encourage everyone who needs this (or other) functionalities to join us on https://github.com/qooxdoo/qooxdoo/ and help extending qooxdoo by creating a pull requests. Thank you.
After digging arround a bit in qx.Class we decided to implement a method qx.Class.getSubclasses which returns a hash object with all subclasses of a given class.
var subclasses = qx.Class.getSubclasses(qx.ui.core.Widget);
gets all subclasses of qx.ui.core.Widget.
Landed in qooxdoo master with commit https://github.com/qooxdoo/qooxdoo/pull/9037
I'm currently writing my first MVVM application which uses EntityFramework for data access.
The Application relies heavly on the underlying database and has to add new Data to the DB in many cases.
However, I'm uncertain about whether or not it is a good idea to call the ObjectContext inside the ViewModel.
e.g.
public class SomeViewModel : ViewModelBase
{
public IEnumerable<User> AllUsers { get; private set; }
private void SomeMethod()
{
var __entities = new DatabaseEntities();
AllUsers = __entities.Users.Where(...).ToList();
}
}
I've seen solutions like this, but there are some question coming along with it.
For example how long the ObjectContext actually lives, or if one should prefer a single, global accessable ObjectContext.
Or should calls like those not be part of the VM in the first place?
Currently I can also imagine to implement like StaticHelpers for each DB table and use Methods like GetAllUsers().
In Josh Smith's sample Application about MVVM he uses a Repository thats injected in the Constructor of each VM.
public AllCustomersViewModel(CustomerRepository customerRepository)
Despite the fact that this has to be a common issue, I found no satisfying answer on how this issue is approached for smaller applications (best practice)?
In the descripton of the DbContext class on MSDN it states "Represents a combination of the Unit-Of-Work and Repository patterns", so it can act as your Repository layer, although it doesn't have to, and it is intended to be used for a "Unit of Work" which doesn't fit using a global one for the entire app. Besides keeping a single one around for everything could cause issues with cached data and other undesirable things (memory usage, etc...).
Hope this helps.
I have a WPF application with MVVM. Assuming object composition from the ViewModel down looks as follows:
MainViewModel
OrderManager
OrderRepository
EFContext
AnotherRepository
EFContext
UserManager
UserRepository
EFContext
My original approach was to inject dependencies (from the ViewModelLocator) into my View Model using .InCallScope() on the EFContext and .InTransientScope() for everything else. This results in being able to perform a "business transaction" across multiple business layer objects (Managers) that eventually underneath shared the same Entity Framework Context. I would simply Commit() said context at the end for a Unit of Work type scenario.
This worked as intended until I realized that I don't want long living Entity Framework contexts at the View Model level, data integrity issues across multiple operations described HERE. I want to do something similar to my web projects where I use .InRequestScope() for my Entity Framework context. In my desktop application I will define a unit of work which will serve as a business transaction if you will, typically it will wrap everything within a button click or similar event/command. It seems that using Ninject's ActivationBlock can do this for me.
internal static class Global
{
public static ActivationBlock GetNinjectUoW()
{
//assume that NinjectSingleton is a static reference to the kernel configured with the necessary modules/bindings
return new ActivationBlock(NinjectSingleton.Instance.Kernel);
}
}
In my code I intend to use it as such:
//Inside a method that is raised by a WPF Button Command ...
using (ActivationBlock uow = Global.GetNinjectUoW())
{
OrderManager orderManager = uow.Get<OrderManager>();
UserManager userManager = uow.Get<UserManager>();
Order order = orderManager.GetById(1);
UserManager.AddOrder(order);
....
UserManager.SaveChanges();
}
Questions:
To me this seems to replicate the way I do business on the web, is there anything inherently wrong with this approach that I've missed?
Am I understanding correctly that all .Get<> calls using the activation block will produce "singletons" local to that block? What I mean is no matter how many times I ask for an OrderManager, it'll always give me the same one within the block. If OrderManager and UserManager compose the same repository underneath (say SpecialRepository), both will point to the same instance of the repository, and obviously all repositories underneath share the same instance of the Entity Framework context.
Both questions can be answered with yes:
Yes - this is service location which you shouldn't do
Yes you understand it correctly
A proper unit-of-work scope, implemented in Ninject.Extensions.UnitOfWork, solves this problem.
Setup:
_kernel.Bind<IService>().To<Service>().InUnitOfWorkScope();
Usage:
using(UnitOfWorkScope.Create()){
// resolves, async/await, manual TPL ops, etc
}
I'm starting up with Entity Framework and RIA Services. I'm also evaluating whether to use POCO or not, I believe it is the way to go since we will work on an agile (scrum) environment... (so far)
With the self-tracked entities I could add decorators on the metadata in order to get client-side validation. How can I achieve the same with POCO classes? I wouldn't want to modify generated files, cause they will be genrated tons of times biefore the final release and (of course) I don't want to write my validation code every time.
Can't you continue to do it with partial classes and metadata types? Something like this.
[MetadataType(typeof(MyEntity.Metadata))]
public partial class MyEntity
{
private class Metadata
{
[Required]
[StringLength(5)]
public string MyProperty;
}
}
When using FxCop 1.36 for a WPF application with a single window that has yet to be modified, I get the InterfaceMethodsShouldBeCallableByChildTypes error with the following details:
Target : #System.Windows.Markup.IComponentConnector.Connect(System.Int32,System.Object) (IntrospectionTargetMember)
Resolution : "Make 'MainWindow' sealed (a breaking change if
this class has previously shipped), implement the method
non-explicitly, or implement a new method that exposes
the functionality of 'IComponentConnector.Connect(int,
object)' and is visible to derived classes."
Help : http://msdn2.microsoft.com/library/ms182153(VS.90).aspx (String)
Category : Microsoft.Design (String)
CheckId : CA1033 (String)
RuleFile : Design Rules (String)
Info : "Explicit method implementations are defined with private
accessibility. Classes that derive from classes with
explicit method implementations and choose to re-declare
them on the class will not be able to call into the
base class implementation unless the base class has
provided an alternate method with appropriate accessibility.
When overriding a base class method that has been hidden
by explicit interface implementation, in order to call
into the base class implementation, a derived class
must cast the base pointer to the relevant interface.
When calling through this reference, however, the
derived class implementation will actually be invoked,
resulting in recursion and an eventual stack overflow."
Created : 08/12/2008 22:26:37 (DateTime)
LastSeen : 08/12/2008 22:41:05 (DateTime)
Status : Active (MessageStatus)
Fix Category : NonBreaking (FixCategories)
}
Should this simply be ignored?
Ignore it, this is standard code that is in every WPF application and you don't see people complaining about net being able to call IComponentConnector.Connect from derived classes - so it's probably safe.
In general I think you should handle FxCop output as suggestions that have to be considered carefully, I've got a lot of bad advice from FxCop in the past.
Depends on what you expect an inheriter to do.
If you are not expecting this class to be inherited then it should be sealed and the problem goes away.
If you are expecting it to be inherited then you are taking the ability of the inheriting class to override the interface methods and still call them (i.e. base.methodname()). If that is your intent then you can ignore the warning.
However, that is not expected behaviour for inheritable classes so you should expose the interface publicly (i.e. An implicit interface instead of an explicit interface).