|
The most common route is to map the OO-objects to a relational model. Your database will need to have it's own design thought out, and preferably, normalized.
OTOH, if you're using it merely as a datastore for said objects, then it might be more beneficial to dive into serialization.
Bastard Programmer from Hell 
|
|
|
|
|
Hi guys Check my example below:
CrazyBitz is an employment agency specializing in matching IT staff with specific skill sets to the needs of prospective employers. An employer might need someone with a c# background and SQL-server experience, who’re also qualified as a CCNA. They need an application that will automatically evaluate how well the skills of applicants match the needs of employers.
Outline arguing that this IS or IS NOT a suitable problem to address with the aid of the decorator pattern...
I say a decorator pattern will be useful since a person that will be employed can have additional skills other than c# and Sql-server as time goes...
What are your personal views about this example?
|
|
|
|
|
A Decorator is used when the original class cannot be "extended" (because it is sealed or final, or written by someone else and you don't have source, etc.). In your example, the skills associated with a person can easily be maintained as an array of skills on the Person class. So this does not qualify as an apt example for a decorator pattern.
|
|
|
|
|
I want to create Architecture for web application using EDMX,WCF and Generics
can any body suggest me the link...
|
|
|
|
|
You don't start with technology - instead you start with business requirements. The requirements drive the technology.
|
|
|
|
|
|
In my recent project, I am trying to implement the dependency injection. This project implements with three tire architecture. One layer is to access database, second one is to manage business logic and last one is for the UI.
Suppose there is a class "Customer" in data layer which implements the "ICustomer" interface for necessary data operations related to the customer. In the business layer, there is another "Customer" class for implement the business logic for the customer entity. This class has an "ICustomer" type property to inject the customer data layer class.
Now my question is, from where I should inject this data objects to business objects? To do this, I have following solutions.
1. Construct the business object and inject the data object from UI layer. But I feel it is ugly because I have to access data layer from UI layer to do this.
2. Create something like factory pattern from business layer to extract business objects with injected data objects. So factory pattern is the correct design pattern for this? If so, how can I implement it? Is there any other method to do this?
Thanks,
Thomas
|
|
|
|
|
SSEAR wrote: 1. Construct the business object and inject the data object from UI layer. But I feel it is ugly because I have to access data layer from UI layer to do this.
Not entirely true. DAL is supposed to be an independent layer so you need another tier(Object Mapping Tier) to make the data transfer from BLL to DAL. See here[^] for the details and the flow of data between the tiers.
Signature construction in progress. Sorry for the inconvenience.
|
|
|
|
|
Thanks for your reply. All the day I was trying to find a solution on google. I concluded with the solution to use a service locator. By the way, several people mentioned that service locator is an anti-pattern. I think it is true in some sense. What do you think about it?
Thanks,
Thomas
|
|
|
|
|
1. You should register all of your services and objects on bootstrap of your application.
2. You always should use factory pattern to instantiate your objects.
3. Service locator gives you another level of abstraction over your DI container, so you may change your container later time if needed.
Mahmud Hasan
Software Engineer from Bangladesh
|
|
|
|
|
You could make your life a HELL of a lot simpler by not attempting to reinvent the wheel - there are loads of DI containers around (Castle Windsor, Unity et al) - take a look and you will probably find it easier (and will definately find it quicker) to use...
C# has already designed away most of the tedium of C++.
|
|
|
|
|
Hi,
I have been trying to refactor the legacy code and make it loosly coupled.
I came across a class which resembles as shown below.
<pre lang="c#">
public Class MyClass
{
private int _a;
private ushort _b;
private int _c;
public MyClass(int a, ushort b, int c)
{
_a = a;
_b = b;
_c = c;
}
public static MyClass FromBytes(byte[] params)
{
int a = BitConverter.ToInt32(params, 0);
ushort b = BitConverter.ToUInt16(params, 1);
int c = BitConverter.ToInt32(params, 2);
return new MyClass(a, b, c);
}
public int A
{
get
{
return _a;
}
set
{
_a = value;
}
}
}
public Class MyConsumer
{
public void MyMethod()
{
// 1st way to create an instance
MyClass myClass1 = new MyClass(2, 3, 4);
int a = myClass1.A;
// 2nd way of creating an instance
byte[] bytes = {8, 7, 6};
MyClass myClass2 = MyClass.FromBytes(bytes);
int a1 = myClass2.A;
}
}
</pre>
'MyClass' has been created in two ways.
- creating an instance using a 'new' operator.
- Through a static method 'FromBytes'.
As seen above MyClass is tightly coupled to MyConsumer class.
I need to provide an abstraction for MyClass.
I thought of creating an Inteface 'IMyClass' which has a property 'A'.
<pre lang="c#">
interface IMyClass
{
int A { get; set;}
}
</pre>
MyClass shall have 2 overloaded constructor as shown below.
<pre lang="c#">
public Class MyClass : IMyClass
{
private int _a;
private ushort _b;
private int _c;
public MyClass(int a, ushort b, int c)
{
_a = a;
_b = b;
_c = c;
}
public MyClass(byte[] params)
{
_a = BitConverter.ToInt32(params, 0);
_b = BitConverter.ToUInt16(params, 1);
_c = BitConverter.ToInt32(params, 2);
}
public int A
{
get
{
return _a;
}
set
{
_a = value;
}
}
}
</pre>
I wanted to create an instance of MyClass in MyConsumer class through
some creational pattern such as Factory.
I don't know how to create an instance of a class which has its constructor
overloaded.
Questions:
- How to provide abstraction to static methods?
- How to create an instance of a class which has its constructor overloaded?
I found this link useful, however it does not server my purpose of creating an object through a factory.
Kindly share your view on this and let me know if you need more information.
Thanks in advance!
|
|
|
|
|
Constructors are a specialised kind of static methods. I often prefer a "normal" static method over a constructor when it has a specialised purpose, e.g. public static MyClass FromFile(string filename).
When it comes to the factory method with overloaded constructors of the classes, there are some possibilities:
- use an overloaded factory method, corresponding to the overloads of the constructors
- use an empty constructor and then set the properties
- create an extra constructor accepting an object[] args parameter
Personally I do not like any of those options, I doubt that the factory method is a good option in such a case.
|
|
|
|
|
Thanks Bernhard for the your time.
If we go with the static methods, I believe it would be tightly coupled and factory seems reasonable to me...
|
|
|
|
|
Use a factory.
The factory is derived from an interface.
The real factory uses the methods on the class that already exists.
The consumer object uses the real factory unless a static method (on option) is called to set a different factory.
|
|
|
|
|
Thanks jschell for your time.
As per my understanding based on your inputs, we need to create a factory.
So, in the sample code, it would be something like this.
interface IMyClassFactory
{
IMyClass Create(int a, ushort b, int c);
IMyClass Create(byte[] bytes);
}
and its implementation would be something like this.
public class MyClassFactory : IMyClassFactory
{
public IMyClass Create(int a, ushort b, int c)
{
return new MyClass(a, b, c);
}
public IMyClass Create(byte[] bytes)
{
int a = BitConverter.ToInt32(params, 0);
ushort b = BitConverter.ToUInt16(params, 1);
int c = BitConverter.ToInt32(params, 2);
return new MyClass(a, b, c);
}
}
Consumer:
public Class MyConsumer
{
public void MyMethod()
{
IMyClassFactory myClassFactory = new MyClassFactory(); // we can inject this
// 1st way to create an instance
IMyClass myClass1 = myClassFactory.Create(2, 3, 4);
int a = myClass1.A;
// 2nd way of creating an instance
byte[] bytes = {8, 7, 6};
MyClass myClass2 = myClassFactory.Create(bytes);
int a1 = myClass2.A;
}
}
Please correct me if I have misunderstood something here. Appreciate, if you can explain with a small example.
Is it acceptable to create an overloaded method in a factory as factory takes and parameter which defines the type of object required?
|
|
|
|
|
public static class FactorySource
{
public static IMyClassFactory Factory { get; set; }
static FactorySource()
{
Factory = new MyClassFactory();
}
}
...
public void MyMethod()
{
IMyClassFactory myClassFactory = FactorySource.Factory;
...
|
|
|
|
|
We've been asked to investigate porting some of our apps to iOS and Android and WinPhone. Currently we are using C++ and target Windows/Lunix (html only version seperate to this). We split the app into 3 layers already, UI, MainLogic and MachineAccess (database, disk, network etc). I accept that UI and MachineAccess are platform specific, and I probably need developers and resources for each platform, but how should I handle the "mainlogic" ?
This mainlogic layer is lots of lines (complex operations) and I dont really want to duplicate it and have to change it in multiple teams/codebases. Do I just have a mainlogic team that publishs the source to the platform teams? (publish and copy) This is kinda what we do for Win/unix but is there a better way? Having a single team on mainlogic is fine, I happy to break the workload along functional lines.
I've also heard that WinPhone wont allow C++/C in the future - any bright ideas how to handle that? Yes we could re-code to a different language, but I suspect sooner or later this problem will occur again.
|
|
|
|
|
Do you think that the mainlogic source will be different for the different platforms? Or only for certain portions?
If the code is (for the most part) the same:
Couldn't you use SCC and share the code over different projects?
If the code is different, could you use an automatic code converter?
We had worked out such a scenario for going from a dying language (VO) to .NET (Vulcan). During the transition period (a year) the code would be transported numerous times from VO to Vulcan until all of it would work. Parts would need a rewrite. The VO code would be adapted too if possible to make the transition possible. The VO code needed to produce valid apps all the time.
An alternative: can you make an abstract in meta language for the 'complex operations'? You can use a code-generator to create the code you need in any language.
Regards ... OttO
|
|
|
|
|
The mainlogic is identical on all platforms, it is essentially a pile of APIs and events. I had figured that SCC was the only way, but I thought there might be a better way now-a-days.
Rewriting the mainlogic away from C++ to another meta language is possible, but the question is then what is a nice future proof generic meta language?
To answer the next reply too - we do have a Web API layer already too (and HTML5 apps) - so I guess those platforms that cannot support C++ just have to use the Web API, unless there is a meta language that solves my problem.
Thanx
|
|
|
|
|
The beauty of a meta language is... you can create your own.
It can also be a pitfall.
Regards ... OttO
modified 2-Mar-12 1:07am.
|
|
|
|
|
If users will typically have internet access on their devices, the main logic could be wrapped up as a web service. No need to throw any of that away, just build the interface. If the apps don't need access to things like cameras, email, contacts etc, create a HTML5 web page(s). That way the apps are no more than a pointer to the web pages.
If this isn't an option, the only real commonality is potentially the webservice otherwise SQLite.
"You get that on the big jobs."
|
|
|
|
|
Richard Brett wrote: but how should I handle the "mainlogic" ?
1. Analyze the existing code
2. Define a limited subset of C++ that allows you implement the existing code. This involves restricting features that currently exist in C++ (such as very limited template use.)
3. If necessary re-write the logic to match the subset of 2.
4. Create translators for the other target languages. Basically cross compilers that translate from 2 to other languages.
5. Add 4 into your build process for the main logic to insure that non-supported features do not creep in.
2/4 can be complex or simple depending on what the code does and what the target languages are.
|
|
|
|
|
Hello 2 all!
I would like to run or participate in a project of compiler (or, maybe, a translator, or an interpretter). During last months I have gained some skills in this area and would like to enlarge them. Now I started writing a compiler of a C-like language right into the machine code (previously I wrote a translator of a C-like code into MASM, compiled programs worked well, so I do have some background). Though, it will be hard to make it alone, maybe by myself I can gather less clear ideas the compiled language could look like. So I would like to find a partner, or maybe just join some beginning project like mine. Any suggestions?
modified 27-Feb-12 17:49pm.
|
|
|
|
|
You might be better to post this in the Collaboration / Beta Testing forum.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
